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How to Use This Manual 


Introduction 


All network installations, regardless of size or complexity, benefit from 
sound planning and efficient implementation. The goal of this guide is 
to give you practical information regarding processes, guidelines, and 
rationale for planning and implementing a NetWare® 4™ network. 


Much of the information included in this guide originated from 
extensive research and testing done by consultants in the Novell® 
Consulting Services group. The processes and rationale in this guide are 
derived from case-proven operations performed by these consultants. 


As with any implementation of a new product release, some 
transitioning is required. Because of NetWare 4’s wide range of new 
technologies, features, and support, the transition may appear greater 
than it really is. 


By following the processes and guidelines in this guide, you will 
discover the best approach and strategy for transitioning your network 
environment to NetWare 4 and identify necessary tasks and scale your 


NetWare 4 project to meet the needs of your organization. 


The processes and guidelines that are provided can be easily tailored to 
your particular project and network infrastructure. 


Once you complete your NetWare 4 implementation, you will see the 
numerous benefits of using NetWare 4 in your network environment. 


Some of the obvious benefits are: 


% Sizing your network into a single view of the entire network for 
simpler access, use, and administration. 
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@ Protecting your existing investments by more than doubling disk 
capacity and adding numerous network services without added 
hardware expense. 


@ Supporting previous NetWare installations by providing full 
backward compatibility with NetWare 3™. 


@ Providing a high level of scalability for managing growth and 
changes in your network. 


General Process and Procedures 


The general process and procedures for designing and implementing 
NetWare 4 can be divided into three phases. These phases are: 


@ Project approach 


@ Design 


% Implementation 


Each phase contains a series of procedures you may or may not need to 
perform, depending on your particular network environment. 





Phase Procedure (Section) 


Rationale 





Project Approach “Organizing and 
Training the Project 
Team” 


“Gathering 
Information and 
Defining the Project 


Helps the project team set realistic expectations so that the 
design and implementation will proceed smoothly. 
Organizing the project in this way also gives members of the 
team an idea of their roles throughout the process. 


Helps the project team identify specific resources, 
organizational and workgroup access, and workflow 
processes within your organization. 





Scope” 

Design “Designing the Helps you set up Novell Directory Services™ (NDS™) so 
Directory Tree that it works efficiently, is easy for network users to employ, 
Structure” and is easy for administrators to manage. It also lays a 
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foundation for completing of the next procedure, designing 
partitions and replicas. 





Phase Procedure (Section) Rationale 


“Determining a Helps provide the scalability, fault tolerance, and 

Partition and accessibility of the Directory across the network. 
Replication 

Strategy” 

*“Planning the Time Helps provide accurate, synchronized time to all servers on 
Synchronization the network. The servers can then apply time stamps to NDS 
Strategy” events and to other services such as messaging applications 


and file systems. 


“Creating an Makes it easier to access network resources and services. 
Accessibility Plan” 

“Designing a Data Helps you avoid data loss or disasters. 
Protection Plan” 





*“Designing an Helps you effectively set up your application for easier 
Application access, load balance, and fault tolerance. 
Management 
Strategy” 
Implementation *“Developing a Makes the actual upgrades and migrations go smoothly. 


Migration Strategy” Setting up a lab helps you avoid the problems that 
administrators could otherwise encounter when trying to 
implement NetWare 4. 


“Creating an Helps prepare the various implementation teams, eliminates 
Implementation confusion, provides efficient execution of tasks, and 
Schedule” communicates migration tasks. 

“Implementing Allows for a trouble free and timely implementation of 


NetWare 4 Services” NetWare 4. 





* conditional procedure 





Identifying Conditional Procedures 


Some procedures are labeled as conditional. When beginning a specific 
procedure, you should first identify if the procedure is conditional or 
not. If so, determine if you need to perform that procedure for your 
network. 
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For example, a procedure for designing time synchronization requires 
that your network have a WAN link or over thirty servers in the 
network. 


The discussion for each conditional procedure begins with a list of 
requirements to help you in decide if you need to perform a specific 
procedure. See “Procedure Requirements” at the beginning of each 
section for information. 


Overview of This Guide 


xii 


“yy 
v 


y 
v 


This guide is a central reference point for information about NetWare® 
4™ design and implementation. After reading this guide, you should 
know how to design and implement a NetWare 4 network. 


Pointers are provided for accessing only the pertinent information for 
your particular network type. Administrators of simple networks are 
guided to information that addresses their particular needs. 
Administrators of complex networks, or those that have WAN link 
considerations, can access critical information useful during their 
planning process. 


This guide contains processes, rationale, and examples of current 
implementations and applications of NetWare 4. For more detail, 
references are provided to the documentation included with NetWare 4. 


In Novell documentation, an asterisk denotes a trademarked name belonging to 
a third-party company. Novell trademarks are denoted with specific trademark 
symbols, such as ™. 


This guide is not a resource for conceptual information about various 
features of NetWare 4. It also does not address issues about complex 
and specific configuration of NetWare 4. Those issues are discussed in 
Novell® Application Notes™ or can be obtained from Novell Technical 
Support documents. 


To set up or maintain a network in the NetWare Enhanced Security configuration 
(the Class C2 evaluated configuration), you must supplement the information in 
this manual with the information in NetWare Enhanced Security Server, 
NetWare Enhanced Security Administration, Auditing the Network, and Security 
Features User Guide. 
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User Comments 


We are continually looking for ways to make our products and our 
documentation as easy to use as possible. 


You can help us by sharing your comments and suggestions about how 
our documentation could be made more useful to you and about 
inaccuracies or information gaps it might contain. 


Submit your comments by using the User Comments form or by 
writing to us directly at the following address: 


Novell, Inc. 

Documentation Development MS C-23-1 
122 East 1700 South 

Provo, UT 84606 USA 


We appreciate your comments. 


User Comments Xiii 
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chapter 


1 Organizing and Training the Project 
Team 


Organizing and training the NetWare® 4™ project team consists of 
defining the team organization, identifying roles, and educating team 
members about NetWare 4 concepts, features, and use. The team will 
manage, plan, and be responsible for all of the implementation tasks to 
be accomplished. 


The following topics are discussed in this chapter: 
@ “Defining Your Team Organization” on page 15 


@ “Determining Team Training Needs” on page 24 


Defining Your Team Organization 


The size of your organization and complexity of your NetWare 4 
implementation determines the framework of your project team. Some 
teams may have one consultant designing and implementing a single 
server and ten workstations, where other teams may have numerous 
people assigned to different specialities across the organization, 
designing and implementing a multisite network with hundreds of 
servers and thousands of workstations. 


Organizing the project team is critical to the efficient design and 
implementation of NetWare 4. The team ensures that implementing 
NetWare 4 is as smooth as possible. 

Before you organize your team, you should: 


% Assess the skills needed to design and implement NetWare 4. 


@ Identify the necessary member roles within the team and who will 
perform those roles. 
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Assessing the Necessary Skills 


The project manager chooses the team members according to 
responsibilities and skill sets. Organizations with preexisting NetWare 
networks can build on the existing skill sets developed from working 
with previous versions of NetWare. 


Organizations setting up NetWare 4 as a new network need to identify 
people with basic networking and communications skills in addition to 
expertise in setting up and configuring NetWare networks. 


Identifying Member Roles 


It is not important how many people are on your project team, however, 
all expectations and concerns for each team member role should be 
represented by some team member. 


Each team member will maintain a high level of expertise in areas of 
management, network administration, or user support service. Not all 
team members need to come from your particular organization. For 
example, it is typical that the wire layout and communication design is 
managed by an outside group. 


Determining the Right Person for the Right Role 


A VÁ 


To determine the person best suited for a specific role, refer to the 
following list of questions: 


LJ = How is the Information Services (IS) department organized? 
LJ Who manages client workstation setup and configuration? 

[d Who manages server setup and configuration? 
Ly 


Who manages the physical network of LAN and WAN hardware 
and software? 


O 


Who makes management decisions concerning networking 
hardware and software? 





L] If your network wire layout or protocols affect the implementation 
of NetWare 4, who is responsible for managing the network wire 
layout? 
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Ll] Who provides training for management, administrators, and 
users? 


LJ Who manages software upgrades? 


[d Who manages network resources such as printers, backup 
software and hardware, file storage, CD-ROM drives, etc.? 


I Who tests and analyzes hardware and software for use on the 


network? 


Identifying Role Responsibilities 


Checklist 


When identifying the specific responsibilities of a project team role, you 
should understand the priorities, expectations, and concerns of each 
role. The following lists will help you identify the responsibilities of 


each role. 


MIS Manager 


This person is a manager or administrator in the group that manages 
design, implementation, and maintenance of your network. This 
person will commonly be project team lead throughout the 
implementation phase and possibly throughout the design phase. 


LJ Priorities 


+ 


+ 


+ 


Coordinating with the Novell® Directory Services™ (NDS™) 
expert to ensure an efficient transition 


Acquiring the appropriate resources and funding to proceed 
with the design and implementation 


Overseeing the design phase 
Coordinating and supervising the implementation phase 


LJ Expectations 


+ 


+ 


Providing direction to the project 


Conveying concerns to and from upper management and 
other departments 


Managing costs 
Organizing meetings 
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LJ Concerns 


+ Designing an efficient network 

+ Managing the cost of implementation, operation, software 
licensing, etc. 

+ Evaluating software 
Creating a timeline for implementation 

+ Handling communication between departments and project 
team members 

+ Affecting user productivity 

+ Training administrators and users 

+ Developing a method and procedure for rollout 

+ Coordinating the pilot implementation 

+ Providing support after implementation 

NDS Expert 


This person has worked with NetWare 4 and NDS or has completed 
training relative to NetWare 4 and NDS. (This role could also be filled 
by a NetWare consultant.) The NDS expert would most likely be the 
team lead in the design process and possibly throughout the 
implementation process. 


Checklist LJ Priorities 


+ 


+ 
+ 
+ 


Creating a Directory tree design 
Desiging NDS security 
Formulating partitioning 
Choosing project team members 


LJ Expectations 


+ 


+ 
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Creating a solid design 


Ensuring that the design is thorough and meets all 
department needs 


Ensuring project team member participation and input 
Meeting timelines 


Checklist 


LJ Concerns 


+ 


Managing expectations of each department and of 
management 


Understanding NDS 


Coordinating login scripts with other concerned team 
members 


Coordinating with other groups 
Assigning someone to document the design 


NetWare Server Specialist 


A server specialist is someone who works daily with NetWare server 


administration. 
LJ Priorities 
+ Maintaining network performance levels 
+ Determining and planning pilot system 
+ Designing time synchronization 
+ Implementing upgrade and migration for the rollout 


LJ Expectations 


+ 


+ 
+ 
+ 


Helping with the lab 

Reducing administration 

Creating standards for protocols usage 

Reviewing and creating standard for frametype usage 


[L Concerns 


9 ©% >% >è >% >% >% è ọ 


Ensuring stability of the network 

Ensuring efficiency and performance 

Planning server placement in the Directory tree 

Calculating needed disk space for new and existing servers 
Maintaining and managing hardware 

Backing up file system and NDS data 

Investigating changes in server utilities 

Preparing for disaster recovery 

Ensuring backwards compatibility 
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+ Ensuring that the server IPX™ address is registered with 
Novell, Inc. 


+ Removing and adding servers 
+ Identifying and setting the bindery context for users 


Workstation Specialist 


This person works daily with users and workstations. This person 
maintains login scripts and loads and upgrades network client 


software. 
Checklist LJ Priorities 
+ Upgrading workstations to the current NetWare Client™ 
software 


+ Automating the client software upgrade 


LJ Expectations 


+ Identifying differences between the NetWare Client software, 
such as differences between the NetWare Client shell 
(NETX), NetWare DOS Requester™, and NetWare Client 
32™ software or between the Mac NDS™ and the NetWare 
Client for Mac OS™ software 


e Creating an efficient implementation schedule for 
workstations 


Updating NetWare Client software 
Identifying any problems with workstation hardware 


LJ Concerns 


+ Determining memory requirements to run NetWare Client 
software 


Identifying necessary changes to configuration files 
Automating the upgrade process 

Identifying performance issues relative to memory usage 
Determining and setting the name context 

Coordinating login scripts with NDS team members 
Testing compatibility 

Determining bindery services needs 


+» ©% ©% è è è è o 


Determining mobile client issues 
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Checklist 


Application Specialist 


This person maintains the application servers and software upgrades 
on client workstations and updates menu systems. 


LJ Priorities 
+ Migrating applications on application servers and client 
workstations 


+ Testing compatibility of applications 


LJ Expectations 
+ Ensuring stability of applications 
+ Providing user access to applications 
+ Updating menu systems or other access to applications 
e Coordinating with NetWare Server Specialist 


LJ Concerns 


+ Determining which applications require support through 
bindery services 


Identifying any compatibility issues 
Ensuring that data is migrated properly 
Developing efficient processes for maintaining applications 


¢- ¢ . + 


Coordinating login scripts with NDS team members 


Printing Specialist 


This person provides access to printers, determines printer locations, 
and upgrades printing software. 
(I Priorities 

+ Providing users with access to printers 

+ Upgrading printer software and drivers 


LJ Expectations 
+ Creating a well-defined migration strategy 
+ Providing easy access to printing resources 
+ Providing efficient use of printing resources 
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LJ Concerns 


+ 


Determining how to set up direct connect printers as 
separate network nodes 


Configuring and administering print services 

Identifying differences between current and previous print 
utilities 

Coordinating login scripts with team members 


Connectivity Specialist 


This person maintains the physical network, the network backbone, 
telecommunications, WAN design, and router placement. 


Checklist LJ Priorities 


+ 


Determining the effect of routing, protocols, 
telecommunications, and WAN structure on the Directory 
tree design 


Making decisions regarding single or multiple protocols on 
the network 


LJ Expectations 


+ 


+ 


Improving network traffic 


Advising the team about routing, protocols, and WAN 
structure 


LJ Concerns 


+ 
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Ensuring that an efficient balance exists between the 
network design and performance of the network over WAN 
links 


Identifying LAN/WAN bandwidth issues 


Identifying necessary protocols and applications used on the 
network 


Setting up and maintaining single or multiple protocols 


a VA 


Checklist 


Testing Lab Coordinator 


This person sets up and tests the networking software with current 
applications, runs diagnostics, and provides statistics on performance 
and network and application software stability. 


m 


Priorities 

e Testing the compatibility between networking software and 
applications 

+ Creating network performance benchmarks 


Expectations 


+ Providing test results about network performance and 
software compatibility 


e Setting up the lab 


Concerns 


e Gathering all network information in order to simulate the 
network environment in the lab 


+ Gathering current versions of application software 
+ Obtaining resources for lab 


Education and Training Coordinator 


This person analyzes the skills required and creates or provides training 
to help administrators and users with network operating procedures. 


m 


m 


Priorities 

+ Identifying and providing implementation and administration 
guidelines 
Training the project team 
Training network administrators 

+ Training users 


Expectations 
+ Working closely with project lead 


+ Researching information that impacts users and 
administrators 


+ Performing on-the-job-training 


Chapter 1: Organizing and Training the Project Team 23 


LJ Concerns 
+ Budgeting for training 
Determining the scope of training 
Setting up the lab to train administrators 
Scheduling training to meet project timelines 


¢- ¢ . + 


Getting team members up to speed before meetings 


Determining Team Training Needs 


The Education and Training Coordinator is responsible for providing 
the necessary training. Education and training can be provided in many 
formats, such as a lab environment for hands-on training or training 
courses through internal or external groups. 


Identifying Training Topics 
Use the following checklist of NetWare 4 concepts to determine the 


prerequisite training needs for your project team members. These 
concepts should be understood before you start your design process. 


Basic NetWare 4 Concepts 


a VA _J NetWare 4 terminology and concepts 





_I Novell Directory Services overview 

Novell Directory Services objects and properties 
Object organization 

Directory tree design 

Novell Directory Services partitions and replicas 
Time synchronization 


¢-¢ >% è% è 


Bindery services 


O Workstation 
+ NetWare Client 32™ for DOS and Windows** 
+ NetWare Client 32™ for Windows 95** 


+ NetWare Client for DOS and Windows (NetWare DOS 
Requester™) 
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+ NetWare Client for OS/2** (NetWare Requester™) 

+ NetWare Client for Mac OS 

+ Workstation configuration 

See NetWare Client for DOS and Windows Technical Reference, 
IntranetWare Client for OS/2 User Guide, IntranetWare Client for 
Mac OS User Guide, NetWare Client for DOS and Windows User 


Guide, and IntranetWare Client 32 for Windows 95 Supervisor 
Guide for more information. 


LJ NetWare 4 utilities 
+ Administrative utilities 
+ User utilities 


See Utilities Reference and Supervising the Network for more 
information. 
LJ Migrating to NetWare 4 
+ New NetWare 4 installation 
+ Migrating NetWare 3™ to NetWare 4 
+ Upgrading bindery to Novell Directory Services 


See Installation for more information. 


New NetWare 4 Features 
Checklist (J File system 
+ File compression 
e  Suballocation blocks 
+ Data migration to high capacity storage systems (HCSS) 


LJ Auditing 
+ AUDITCON utility 
+ User auditor 


l] NetWare 4 Print Services 
+ New features and requirements 
+ Printing software and utilities 
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l] Backup and restore 
+ Hardware and software independence 
+ Types of backup systems 
e Target Service Agent (TSA) 


Advanced NetWare 4 Concepts 


EN. LJ Architecture 


Security enhancements 





Ly 
J NDS synchronization 
Ly 


Internationalization 


See Supervising the Network and Concepts for more information. 
Identifying Training Opportunities 
There are several types and sources of NetWare training available. 


Novell Education 


The following table lists the official Novell® training courses available: 


Course Number Course Title 





105 Introduction to Networking 

200 Networking Technologies 

216 Fundamentals of Internetworking 

520 NetWare 4.11 Administration 

525 NetWare 4.11 Advanced Administration 

526 NetWare 3.1x to NetWare 4.11 Update 

527 NetWare 4.1 to NetWare 4.11 Update Seminar 
528 NetWare 4.1 to NetWare 4.11 Update Workshop 
532 NetWare 4.1 Design and Implementation 
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Course Number Course Title 





801 NetWare Services and Support 
804 NetWare 4.11 Installation and Configuration Workshop 
960 NetWare Programing: Directory Services 





Instructor-led courses are also available through Novell Authorized 
Education CentersóM (NAEC™) and Novell Academic Education 
Partners™ (NAEP™). Computer-based training products, videos, and 
self-study workbooks are available through NAECs, Novell resellers, 
and Novell After Market Products. 


For more information or to find the NAEC or NAEP nearest you, in the 
United States and Canada call 1-800-233-EDUC. In all other areas, call 
1-801-861-5508, or contact your nearest Novell sales office. 


A quick 24-hour-a-day tool for information is Novell Education 
FaxBack. Call 1-801-861-5363 for access to FaxBack. Ask for document 
1448 for current courses. Ask for additional documents listing the 
NAEC in your area and the courses they offer. 


BrainShare 

Some of the best material presented about NetWare 4 and other Novell 
products are presented during Novell's BrainShare™ conference. 
BrainShare conferences are held in Salt Lake City, Utah; Europe; Japan; 
and Australia. 

For more information in the United States and Canada call 


1-800-NETWARE. In all other areas, call 1-801-861-5508, or contact your 
nearest Novell sales office. 


Seminars 


Helpful seminars are held in the local Novell sales offices. Your local 
account representative can assist you. 


Novell Consulting Services Workshops 


Novell Consulting Services (NCS) develops and delivers workshops to 
our Consulting Partners. If you are not a Consulting Partner, contact 
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Novell Consulting Services for an invitation to attend the workshops 
for a fee. 


NCS provides a copy of the NCS Toolkit to all attendees of the 
workshops. 


The Toolkit provides design and implementation methodologies for all 
Novell products. Tips and tricks that were learned through site visits 
and testing are also included. 


AppNotes 


Current AppNotes™ are a good source of NetWare 4.1x information. 
Older AppNotes that are based on NetWare 4.0, 4.01, and 4.02 should 
be discarded. 


For more information in the United States and Canada call 
1-800-377-4136 or (303) 297-2725. In all other areas, call (303) 297-2725, 
or contact your nearest Novell sales office. 


NUI Groups 


Joining the local NetWare User Group allows you to share information 
and experiences with other NetWare 4.1x users. Novell engineers and 
consultants are often invited to speak on topics of interest. 


For more information in the United States and Canada call 


1-800-228-4684. In all other areas call (801) 228-4538, or contact your 
nearest Novell® sales office or NetWare Users International group. 


Where to Go from Here 





To Go to 

Begin your NetWare 4 project Chapter 2, “Gathering Information 
and Defining the Project Scope,” on 
page 29 
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chapter 


2 Gathering Information and Defining 
the Project Scope 


Information about your organization’s workflow, communication 
layout, organizational structure, and resources will help you identify 
the scope of the design project and framework of the design. 

You will need to gather information about your organization. This 
information will be reference material for determining the best 
approach to rights structures, resource access, performance tuning, and 
management for your NetWare® 4™ implementation. 

The following topics are discussed in the chapter: 


@ “Determining What Information Is Needed” on page 29 


@ “Defining the Project Design Scope” on page 34 


Determining What Information Is Needed 


Team members need to determine what information will best support 
the decisions they need to make. The information should be as current 
and detailed as possible. This ensures that your design will match your 
organization’s real implementation of resources and workflow. 
You should gather the following types of documents and information: 
@ Organization chart 
@ Resource lists 
@ Workflow information 


@ Location maps 


@ Maintenance schedules 
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@ LAN/WAN topology maps 


% Configuration information 


MIS Manager 


The following table list the type of information needed by the MIS 


manager: 





Information Type 


Purpose 





Organization 
chart 


Resource lists 


Workflow 
information 


Location maps 


Maintenance 
schedules 


Shows how the organization is structured. 


Lists all the network resources that need to be 
incorporated into the Directory tree. 


Helps determine how to best accommodate the 
organization’s workflow so that little or no downtime is 
experienced. 


Shows how resources are allocated throughout the 
organization and where those resources are located. 


Helps determine when specific network tasks are being 
performed, such as backup and software and hardware 
upgrades. 





NDS Expert 


The following table lists the type of information needed by the NDS 


expert: 





Information Type 


Purpose 





Organization 
chart 


WAN topology 


LAN topology 


Identifies the major divisions and workgroups within the 
organization. 


Determines how many sites exist in the organization and 
what types of WAN links exist between sites. 


Identifies what major resources exist and where they are 
located. Helps determine wire type and configurations. 
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Information Type Purpose 





Location maps Helps identify regional areas. 
Workflow Helps determine how information flows through the 
information organization. 





NetWare Server Specialist 


The following table lists the type of information needed by the NetWare 
server specialist: 





Information Type Purpose 





WAN topology Shows how many servers exist and where they are 
located. Helps identify what function NetWare servers 
perform for WAN communications. 


LAN topology Shows how many NetWare servers are in a given LAN 
segment. Helps identify servers with unique 
configurations. 

Location maps Identifies regional areas. 

Resource lists Lists all the NetWare servers and their locations. Helps 


determine what type of client support is needed and what 
versions of software exist or are needed. 


Configuration Lists specific information about each NetWare server's 
information specific hardware configuration, settings, and software 
version. 
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Workstation Specialist 


The following table lists the type of information needed by the 
workstation specialist: 





Information Type Purpose 





Resource list Identifies how many workstations need to be upgraded 
and what type of hardware exists. 


Configuration Lists specific information about each workstation’s 
information hardware configuration, settings, and software version. 
WAN topology Shows how many sites exist in the organization and what 


type of access is needed to the network. 


LAN topology Identifies how many workstations exist on a specific LAN 
segment and what wire type and configurations are used. 


Location maps Identifies regional areas. 
Workflow Helps determine when and how workstations access and 
information use information. 





Application Specialist 


The following table lists the type of information needed by the 
application specialist: 





Information Type Purpose 





Resource list Identifies how many licenses are needed to support each 
platform. Helps determine if software versions need to be 
upgraded. 

LAN topology Identifies which servers are used to store applications 


and how the servers are accessed. 


Configuration Shows specific information about each application’s 
information configuration, settings, and software version. 

Workflow Helps determine which applications are needed at which 
information locations. 
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Printing Specialist 


The following table lists the type of information needed by the printing 


specialist: 





Information Type 


Purpose 





Resource list 
LAN topology 


Configuration 
information 


Connectivity Specialist 


Helps determine how many printers need upgraded 
drivers. 


Identifies where printers are located and what 
workgroups access each printer. 


Shows specific information about each printer’s 
configuration, settings, and driver version. 


The following table lists the type of information needed by the 
connectivity specialist: 


Information Type 


Purpose 





Resource list 


LAN topology 


WAN topology 


Location maps 


Configuration 


information 


Workflow 
information 


Identifies which protocols should be supported. 


Helps identify how the LAN is routed to determine if a 
more efficient method can be used. 


Helps determine the speed of WAN links between each 
site. Identifies how often remote sites dial in. 


Shows how information is being routed and if a more 
efficient method can be used. 


Shows specific information about each application’s 
configuration, settings, and software version. 


Helps determine what applications are needed at which 
locations. 





Testing Lab Coordinator 


The following table lists the type of information needed by the testing 


lab coordinator. 
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Information Type 


Purpose 





Resource list 


LAN topology 


WAN topology 


Configuration 


information 


Workflow 
information 


Identifies typical server and workstation configurations 
and setup. 


Helps identify the kinds of routing LAN configuration that 
need to be simulated. 


Helps identify the kinds of WAN links that need to be 
simulated. 


Helps determine the types of configuration that need to 
be simulated. 


Shows what applications and resources are being used. 


Education and Training Coordinator 


The following table lists the type of information needed by the 
education and training coordinator. 





Information Type 


Purpose 





Organization 
chart 


Resource lists 


Workflow 
information 


Shows which groups need training and identifies key 
contacts for scheduling training. 


Shows what training needs to be done to use new 
software. 


Helps determine current processes and how those 
processes can be improved by the new technology. 


Defining the Project Design Scope 


Before starting your NetWare 4 design, determine the project scope and 
timelines. The complexity of your organization’s setup will determine 
the size and length of the NetWare 4 design phase. 


To determine the scope of this project, ask yourself: 


% How long will it take? 
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@ Are we going to implement the design throughout the 
organization? 


Identifying Critical Factors 


Critical factors for evaluating the scope of the NetWare 4 design 
include: 


@ Determining complexity 


@ Identifying expectations 


Determining Complexity 


The following table reviews the factors that help determine the 
complexity of your organization: 





Factor Simple Complex 

Custom partitions Fewer than 5 servers, More than 5 servers, 
single site multiple sites 

Time synchronization Fewer than 29 servers, 30 or more servers, 
single site multiple sites 

Number of locations One Multiple 

Number of servers Fewer than 5 Multiple 

Number of users Fewer than 1000 More than 1000 objects/ 
objects/users users 

Setting up a testing lab No lab Set up lab 

Organizational vs. Add time to planning Add time to planning 

departmental process if expecting process if expecting 

implementation growth or merger growth or merger 


If you have a simple network, you should accept default settings in 
most cases. If you have a complex network, review the following list to 
determine the implications for each criteria: 


Y LJ  5or more servers 
+ Design custom partitioning 


Chapter 2: Gathering Information and Defining the Project Scope 35 


Identifying Expectations 


+ Design custom replication 


30 or more servers 
+ Design time synchronization 
+ Set up test lab before implementation 


Multiple sites 
+ Design partitioning 
+ Design time synchronization 


Multiple Directory trees in your organization 
+ Determine who shares resources 
+ Identify possibility of merging 


Multiple NetWare versions throughout the entire network 


+ Involve several groups to plan and implement across the 
entire organization 


+ Plan thorough integration testing of applications, utilities, 
hardware, etc. 


Possible growth of sites and number of network servers 
+ Perform a more complex design 
+ Plan for a more complex implementation 


Review the complexity and determine the expectations for the design 
project, including 


+ 


+ 
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How long will the project last? 
What is the budget? 
Who will be on the project team? 


Will the implementation be across the whole organization or select 
areas? 


Are there any other critical needs from management? 


Creating a Design Phase Schedule 
Part of the project approach includes listing the tasks to be performed 


in the Design phase and estimating timelines for completing them. Use 
the procedures in the Design phase to create your timeline. 


Creating New Documentation 
Examples of planning documents are provided to help you manage and 
implement NetWare 4 on your network. You should customize these 


examples to fit your specific network environment. 


See Appendix C, “Template Examples,” on page 277 for more 
information. 
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Where to Go from Here 


To Go to 





Organize network resources into Chapter 3, “Designing the Directory 
logical units within a Directory tree Tree Structure,” on page 39 


Scale the size of your network for Chapter 4, “Determining a Partition 
better accessibility and fault tolerance and Replication Strategy,” on page 85 


Establish a method for ensuring that Chapter 5, “Planning the Time 
network time is consistent among all Synchronization Strategy,” on 


network servers page 107 
Determine an efficient plan for Chapter 6, “Creating an Accessibility 
accessing network resources Plan,” on page 125 
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chapter 3 


Introduction 


“yy 
v 


Designing the Directory Tree 
Structure 


This chapter describes the process for designing a Directory tree. The 
following topics are discussed: 


e “Creating a Naming Standards Document” on page 45 
e “Planning the Directory Tree Structure” on page 52 


@ “Planning Placement of Network Resources” on page 69 


The Novell® Directory Services™ (NDS™) technology allows you to 
develop a common, distributed Directory database of logical and 
physical resources regardless of where the resources are physically 
located —forming a single information system. 


The term Directory used in Novell Directory Services is capitalized in this 
document to differentiate it from the term directory used in the file system. 


Applications that have traditionally maintained Directory databases 
such as e-mail, human resources, and network management 
applications can now share a common source of Directory information 
that is available from any server in the network. This greatly enhances 
access to and management of resource information for the entire 
network. 


All NetWare® 4™ servers on the network access the Directory database 
for information about network resources and access to those resources. 
Because of this, network information is not server specific. Each 
network resource is represented by a unique entry in the database and 
is accessed by its name, not by its association to a particular server. 


All network clients access information and resources through a single 
connection to the network. 
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X.500. Some implementations of the X.500 standards within NetWare 4 may 
differ from those described by CCITT (Consultative Committee for Telegraphy 
and Telephony). This is because many of specifications were being defined after 
Novell® completed development of NDS. 


y Novell Directory Services (NDS) is consistent with the international standard, 
v 


Object-Oriented Database 


NDS is an object-oriented implementation of a Directory that allows 
you to build sophisticated naming schemes and logical representations 
of network resources. The objects used in NDS are referred to as 
Directory objects. 


Directory objects are structures that store information; they are not the 
actual entity represented by the object. For example, a Printer object 
stores information about a specific printer and helps manage how the 
printer is used, but it is not the actual printer itself. 


The specific information that is stored for each object then becomes the 
directory information that can be used by applications and resources 
across the entire network. The Directory information is stored in the 
Directory database. 


Directory objects consist of categories of information, known as 
properties or attributes. These properties act as data fields within an 
object for defining specific information about the object. 


Some properties contain vital network information, such as printer 
names, network addresses, and configuration information. Other 
properties contain non-vital information, such as a user's job title, 
telephone number, and street address. The specific property 
information is referred to as an object’s property value. 


Some property values are required. An object cannot be created without 
these values, and these values cannot be deleted. For example, a User 
object requires both the name of the object and a value for the user’s last 
name. 


Many properties are multivalued. This means that more than one value 
can be set for a given property of an object. For example, values for 
multiple phone numbers can be set in the Telephone Property of a User 
object. 


40 Place Book Title Here 


Object Classes 


The following figure illustrates the properties of a User object. 


Object Property 


Login name 


Esayers 





Email address 


Esayers@ACME 





Telephone number 





The Directory database contains three types or classes of objects: 








555-1234 
551-4321 


+ [Root] object (Directory tree name) 


% Container objects 


% Leaf objects 


These objects represent both actual and logical resources in the 


network, such as users, printers, groups, and print queues. 


Directory Rules and Definitions 


Base Schema 


NDS maintains a system of rules and definitions for object properties 
that establishes the content and format of each object. This system of 
rules and definitions is called the Directory schema. 


The basis for all entries in a Directory database is a set of defined object 


classes referred to as the base schema. Object classes such as servers, 


users, and print queues are some of the base object classes defined by 


the base schema. 
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Schema Extension 


y 
v 


The NDS schema can be modified and extended to suit the specific 
needs of your organization. Object class definitions can be added to and 
modified for the existing base schema. This is consistent with the X.520 
specifications defined by CCITT. You can extend the NDS base schema 
by using Novell’s Directory Application Programming Interface (API) 
to create new objects, class definitions, and properties as well as by 
adding properties to existing class definitions. For example, you may 
need a special object to represent a group of compact discs that could be 
reflected on all NDS servers in the tree. 


The complete list of flags associated with each property can be found in the 
Novell Directory Services Schema Specification, which is part of the NetWare 
server SDK. 


However, the Novell 4.11 utilities will not allow you to add or modify objects in 
your new object classification. You will need to create utilities that can manage 
these new objects along with the currently defined NDS objects. 


Directory Tree Structure 


y 
v 


Directory objects are organized within the database by creating a 
hierarchical structure with multiple levels of organizational units, 
users, groups, and other network resources. This hierarchical structure 
is referred to as the Directory tree. 


The Directory tree replaces the bindery (flat file system) that was used in 
previous versions of NetWare. 


The way in which objects are created and structured in the Directory 
tree is determined by the physical and organizational environments of 
your network. 


Directory Tree Design 


The size of your network isn’t as important as the environment your 
network exists in—the network’s hardware, communication links, 
LAN/WAN topology, and your organization’s structure. 


The complexity of your network’s physical and organizational 
infrastructure determines the amount of designing necessary to 
efficiently implement the NDS technology—the more complex your 
environment, the more designing you need to do. 
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For example, a small network with multiple WAN links might have 
many more design concerns than a large network with no WAN links. 
This is because of unique physical attributes associated with different 
WAN architecture types. 


Generally, four types of network environments affect the design of a 
Directory tree: 


Network Environment Description 





Single server network | Typically maintains only LAN connections. The 
entire network is housed in one building or office and 
all connections lead to a single server. 








Single location Typically maintains only LAN connections. The 

network entire network is housed in one building or office. 
Single campus Typically maintains only LAN or high speed WAN 
network connections. The entire network is located at one 


site, in one or more buildings. 





Multiple campus Typically maintains connections between campus 

network sites. It relies on data transmission across LAN and 
WAN links, with issues concerning speed and 
volume. 








The Directory tree design is the most important procedure in the design 
phase. All other NetWare 4 design is based on the tree structure that you 
create. Nevertheless, NDS is extremely flexible and will allow 
modifications to the Directory tree structure as your organization 
changes. 

An efficiently designed tree 


@ Ensures that NDS object values are consistent, which makes 
networks easier to access and manage. 


@ Makes the successful design of partitions and replicas possible. 
% Accommodates growth of the network without exacting revisions. 


@ Makes merging Directory trees easier. 
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@ Makes the designing of other network services and accessibility 
easier. 


@ Makes navigating the tree more intuitive. 


@ Increases efficiency of network resources because they are 
available from anywhere in the network with a single login. 


Objectives 


Designing a Directory tree structure consists of creating a NDS naming 
standard and designing the Directory tree to best suit your 
organization’s network environment. You will use the information that 
you gathered about your organization’s workflow, communication 
layout, organizational structure, and resources to determine the actual 
framework of your tree design. 


Prerequisites 


“NV 1 You should have copies of the following planning documents: 
+ Organizational charts 

Resource maps 

Location maps 

LAN and WAN topology maps 


+. ©% . + 


Workflow information 


_J You must have organized a project team 





I Each project team member must be educated about NetWare 4 
concepts 
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Creating a Naming Standards Document 


Naming standards detail the conventions you will use for naming 
Directory objects. Standards should also specify how you will enter 
property values (such as telephone numbers and addresses) for the 
objects. 


You should create a document and distribute it to those responsible for 
adding or moving objects in the Directory tree. If standards are in place 
for using the Directory, users and administrators can better use the 
Directory tree. 


Searching and browsing rely heavily on the ability to search the 
Directory based on criteria from the user. If the object names follow a 
standard, then searching is simpler. 


For example, if all laser printers are named “LJuniquename,” where 
uniquename is more descriptive, then a search for all printers named 
“LJ*” is feasible. 


Using a Naming Standards Template 


Use the naming standards template example to determine an 
appropriate naming standards document for your organization 


The following example provides standards and rationale for 
developing a naming standards document. 


Table 3-1 
Naming Standard Example 





Item Standard Examples Rationale 
User object First initial, middle msmith, Using unique names company-wide 
common name initial (if applicable), bgashler is not required by NDS but helps 
(login name) last name (all lower avoid conflicting names in the same 
case), 8 characters context. 
maximum. Allcommon ; ene 
names are unique in An 8-character maximum simplifies 
the company user home directory creation. 
User object Last name (lowercase) poulton Using lowercase for the last name 
last name helps distinguish it as the last name 
of a user. 
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Table 3-1 


Naming Standard Example 








Item Standard Examples Rationale 
User object Numbers separatedby US: Avoid parentheses, commas, or the 
telephone and fax dashes 123-456-7890 long-distance number “1-”. 


User object 
location 


Directory tree 


Organization 


Organizational Units 
whose names are 
based on a major 
location 


Other OU names 
Common names of 


leaf objects other than 
users 





Two-letter location 
code (uppercase), 
dash, mail stop 


For the main corporate 
tree. Use a location 
name for other trees if 
necessary. 


ACME for all trees 


Two-letter location 
code 


Department name or 
abbreviation 


Unique company-wide 


One-letter object 
class, dash, two-letter 
location code, brand or 
department 
information, unique 
number 
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Other: 
44-344-123456 


BA-C23 


ACMECORP 


ACME 


AT, CH, CU, LA, 
BA, BO, DA, MU 


Sales, Eng 


LaserJet 4 
printer in 
Chicago: 
P-CH-LJ4-023 


Engineering 
server in 
Chicago: 
S-CH-Eng-1 


This field is expected to be used by 
autodialing software. 


This field is used by interdepartment 
mail carriers. 


Separate trees may be created for 
sites where connection to the 
corporate tree is not economical. 


A standard Organization name 
allows for future merging of trees. 


Short, standard names are used for 
efficient searching. 


Short, standard names are used for 
efficient searching. 


Avoid extremely long names; some 
utilities will not display them. NDS 
requires server names to be unique 
in the tree. 


Table 3-1 


Naming Standard Example 


Item 


Standard Examples 


Rationale 





Special objects 


+ Organizational Role Administrative role the PrintAdmin 


+ Profile 


e Directory Map 


All 





Organizational Role 
performs 


Name should reflect MobileUser 
the purpose of the 


profile 


Directory name where DOSAPPS 
application has been 
installed 


Avoid special 
characters such as :. + 
=/\ 


Avoid spaces 


Short, standard names are used for 
efficient searching. 


Special characters are not allowed 
in utilities. Spaces demand the use 
of quotation marks in some utilities. 


See Appendix C, “Template Examples,” on page 277 for a copy of a 
naming standards document template. 


Identifying Naming Considerations 


Concise and meaningful object names make it easier to use the 
Directory tree. Keeping names short reduces the amount of data going 
across the wire, simplifies logins, and makes names easier to remember. 
To ensure that object names are concise, consider the following: 


@ Consistency 
% Name length 
% Compatibility 


% Conventions 
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Consistency 


Consistent naming standards provide a guideline for network 
supervisors who will be adding servers, creating users, modifying and 
moving objects, etc. Consistent standards also make it easy for users to 
search for specific items in the Directory tree. 


you do not need to have it perfected before you implement NDS. You can 
rename objects and move subtrees to reflect any changes you want to 
implement. 


“y Although a consistent naming standard for the corporate network is important, 
v 


Name Length 


Ensure that the naming schemes are short, yet as descriptive as 
possible. For example, “SW Engineering” could be shortened to 
“SWEng.” 


All object names can contain up to 64 characters in their Name property 
(the name given when an object is created). 


Compatibility 
Some compatibility issues exist that you should consider, such as 


@ Backwards compatibility 


When you create objects to be accessed from a client workstation 
running the NetWare Client shell software, such as NETX, the 
names of the objects must follow bindery naming rules or the 
NetWare Client shell software cannot recognize them. Object 
names in bindery services are interpreted as follows: 


@ Spaces in object names are replaced by underscores 
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@ Object names are cut off after the 47th character 


You cannot use the following characters in an object name that 
must be accessed from a client running a version of NetWare 





earlier than NetWare 4: 

Character Description Character Description 

/ Slash [] Square brackets 

\ Backslash <> Angle brackets 
Colon Vertical bar 

: Semicolon + Plus sign 

> Comma = Equal sign 

7 Asterisk ? Question mark 


Note WAV The object naming rules apply to most objects. See the documentation provided 
Y with your application to obtain specific naming rules. 


@ DOS commands 


Avoid using spaces because they make it more difficult for users 
to reference objects from the DOS environment. If you want to use 
a space in names, use an underscore character ( _ ) instead of a 
space. NDS treats spaces and the underscore character 
interchangeably. 


International 


Unicode® is a wide character encoding scheme that provides the 
basis for internationalization of the information in an NDS 
database. All character strings exchanged between a NetWare 4 
server and a client workstation are in Unicode. The NetWare client 
software handles the translation of Unicode strings. 


Occasionally, however, you might use characters that Unicode 
cannot translate. When this happens, the character is substituted 
in your display as a “heart” symbol in DOS and as a box symbol 
in Windows”. 
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Substituted characters can prevent NDS from recognizing an 
object. See “Code Page” and “Unicode” in Concepts for more 
information. 


@ IPX numbers 


You may want to set standards for IPX internal and external 
network numbers. This makes setting up servers more difficult, 
but it can simplify troubleshooting and packet filtering. 





Type 


Explanation 





IPX 

external 
network 
number 


IPX 
internal 
network 
number 
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The IPX external network number consists of eight hexadecimal 
digits (0 through F) which identify the cable segment. A new IPX 
external network number is assigned to each segment for 
additional protocols or frame types. 


The IPX external network number is specified in a server’s 
AUTOEXEC.NCF file by the BIND parameter “NET=”. When 
you use INETCFG.NLM to configure protocols, the number is 
called the “ID String.” 


You can set standards for the IPX external network number by 
assigning codes for the digits. For example, you could specify 
that all cable segments in Chicago begin with the digits 01. The 
remaining digits could further narrow the location of the cable 
segment or the type of protocol. 


The IPX internal network number is also an eight-digit 
hexadecimal number. It is specified in the server's 
AUTOEXEC.NCF file to uniquely identify the server on the 
network. 


The server installation program normally generates a unique 
IPX internal network number, though it does allow the installer 
to specify one. 


Like the external number, you can set standards for the internal 
number to help locate the source of packets during 
troubleshooting. For instance, you could specify that all cable 
segments in Chicago begin with the digits 01. The remaining 
digits could further narrow the location or type of the server. 


A VÁ 


NetWare Server objects 


The NetWare Server object for a NetWare 4 server must be created 
with INSTALL. The object is given the same name as the physical 
server. To see rules for naming physical servers, press <F1> (Help) 
in INSTALL. 


If you create a NetWare Server object for servers that are not 
running NetWare 4, you must ensure that the object name is the 
same as the server name. This is because NDS searches for the 
server by name to verify its existence. 


Because of these restrictions, we recommend renaming NetWare Server 
objects by changing their names in the AUTOEXEC.NCF file. 


Service Advertising Protocols (SAP) 


Unique names are required for all devices on the network which 
send out Service Advertising Protocols (SAP). File and print 
server names, even though they are stored in NDS, need to be 
unique because they use SAP. 


Conventions 


Use the following guidelines when creating your naming conventions: 


+ 


Use consistent capitalization to ensure readability and to 
differentiate between container objects and leaf objects. 


To facilitate administration when working at the command line, 
avoid using spaces. Use hyphens or underscores instead. 
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+ 


To ensure compatibility with bindery services, limit names to 47 
characters, and do not use the following characters in object 
names: 








Character Description Character Description 

/ Slash [] Square brackets 

\ Backslash <> Angle brackets 
Colon Vertical bar 

: Semicolon + Plus sign 

; Comma = Equal sign 

. Asterisk ? Question mark 


Assign user login names using the first initial of the first name and 
then up to seven characters of the last name. For example, user 
John Smith would have a login name of JSmith. 


Planning the Directory Tree Structure 


Novell Directory Services supports many different Directory tree 
structures. This flexibility ensures that your tree design is the most 
efficient for your particular network environment. To ensure that you 
build the most efficient structure, you should maintain four goals: 


+ 


+ 


Provide intuitive and efficient access to network resources. 


Provide secure access to shared resources that is easily maintained 
and monitored. 


Develop a clear and concise blueprint for completing the 
implementation process. 


Develop a flexible layout of the tree structure to ensure that future 
changes can be easily incorporated. 


The basic design principles provided in this section should assist you in 
accomplishing these goals. 
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You should build your tree structure by actually drawing each layer of 
the Directory tree as you read the following discussions. You can use 
modeling or drawing software, or create diagrams of the structure on 


paper. 


The most helpful documents for this procedure are organization and 
resource charts, location maps, and WAN topology charts. 


Designing Upper Layers 
Structuring the upper layers of the Directory tree is important to the 
general foundation of the tree and the tree performance. The upper 
layers are mostly affected by the WAN topology and speed of WAN 
links. This affects the kind of partitions and replicas you can use. 
The upper layers include the following objects: 
@ [Root] object 
% Organization objects 
e First layer of Organizational Unit objects 
These layers build a solid framework for the bottom layers to be built 


upon. A few users and network resources need to be placed in the 
upper layers of the tree. 


Naming Your Directory Tree 


The highest object in the Directory tree is the [Root] object and is given 
the tree name. The [Root] object resides at the top of the tree and all 
other objects branch downward from it. 


The [Root] object can be created only by the NetWare 4 installation 
program, which automatically places it at the top of the tree. Once the 
[Root] object is named, it can only be renamed by the DSMERGE utility. 


A Directory tree name must be unique. Use a name that identifies your 


network and the organizational environment that the tree is designed 
for. 
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For example, a company that is named ACME Corporation and 
maintains a world-wide network might simply name their Directory 
tree ACME _ CORP. 


Important Multiple Directory trees can exist on the same network, but each tree needs a 
unique name. 


Workstations use the tree name to connect to a server within the correct 
Directory tree. Network utilities reference the tree name by its unique 
name or by the [Root] object. Many utilities only refer to the object as 
[Root]. 


The Directory tree name or [Root] object can have trustees, and the 
rights granted to these trustees flow down the tree. One example is the 
User object ADMIN, which is created automatically during installation. 


Determining the Directory Tree Foundation 


The general foundation of the Directory tree is established through 
container objects. These objects represent the organizational and 
physical structure of the network. 


Container objects hold (or contain) other Directory objects. Container 
objects provide a means of logically organizing all other objects in the 
Directory tree. 


There are five kinds of containers: 


% Country (C) 


The Country object designates the country where your network 
resides and organizes other objects within the country. This object 
is consistent with the X.500 specifications and is generally used by 
global directory providers as an entry point into their directory 
systems. 


Note WAV Novell Directory Services more commonly uses Organizational Unit 
Y objects to represent geographical boundaries within an organization. 
If you are not planning to use a third-party Directory provider, using the 
Country object might add an unnecessary level of complexity. If in the 
future the Directory tree needs the Country designator or needs the object 
added for merging with another tree, you can then add the Country object. 


When used, the Country object must be placed directly below the [Root] 
object. 
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Figure 3-1 


Example of a Tree Design with and without a 


Country Object 

















Usage of Country No Country name Usage of Country with No Country name - 
multiple Organizations multiple Organizations 
ACMECORP. ACMECORP. AGCMECORP. 
C (O)=ACME ) C (O)=ACME _) ((O)=ACME_ EURO) (_ (O)=ACME _) ((O)=ACME EURO ) 
e Locality (L) 


my 


The Locality object designates the location where this portion of 
your network resides and organizes other objects within the 
location. 


The Country and Locality objects are characteristic of the X.500 
specification, but are not commonly used within the Novell 
Directory Services design. This chapter does not discuss design 
information for using Country or Locality objects. 


Many NetWare 4 utilities do not recognize the Locality object. Use this 
object only when necessary for compliance with the X.500 specifications. 


When used, the Locality object can be placed below the [Root] 
object, Country object, Organization object, or Organizational 
Unit object. 


Licensed Product (LP) 


Licensed Product objects are created automatically when you 
install a license certificate or create a metering certificate using 
NetWare Licensing Services™ technology. 


When an NLS-enabled application is installed, it should add a 
Licensed Product container object to the Novell Directory 
database and a License Certificate leaf object to that container. 


When used, the Licensing Product object can be placed below the 
[Root] object, Country object, Organization object, or 
Organizational Unit object. 


For more information, see Chapter 10, “Managing NetWare 
Licensing Services” in Supervising the Network. 


Chapter 3: Designing the Directory Tree Structure 55 


% Organization (O) 


An Organization object helps you organize other objects in the 
Directory tree. It also allows you to set defaults for User objects 
you create in the Organization container. 


You can use an Organization object to designate a company, a 
division of a company, a university or college with various 
departments, or a department with several project teams. 


Every Directory tree must contain at least one Organization object. 


Organization objects must be placed directly below the [Root] 
object, unless a Country object or Locality object is used. 


% Organizational Unit (OU) 


An Organizational Unit object helps you organize lower layer 
containers and other objects in the Directory tree. It also allows 
you to establish system level login scripts and to create a user 
template for User objects you create in the Organizational Unit 
container. 


You can use an Organizational Unit object to designate a business 
unit within a company, a department within a division or 
university, or a project team within a department. 


This object is optional. When used, Organizational Unit objects 
must be placed directly below an Organization, Organizational 
Unit, or a Locality object. 


Establishing Tree Boundaries 


Create container objects to establish a logical representation of the 
organizational and physical network infrastructure. This allows you to 
establish tree boundaries that facilitate efficient administration, 
scalability, security, and access to network resources. 


The most helpful documents for this task are organization charts, 
location maps, and WAN topology charts. 
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Forming an Organization Layer 


Novell Directory Services requires that at least one Organization object 
exist in the Directory tree. Organization objects can reside directly 
under the [Root] object or under a Country or Locality object. 


Generally, a single Organization object is created directly under the 
[Root] object. It identifies an organization’s name and provides a level 
of administration for the entire tree. 


For example, a network administrator might set a specific set of file 
system rights for all files on network servers, or establish a system login 
script that is used for all users within an organization or department. 


A single Organization object under the [Root] object also allows for 
easier merging of trees with other organizations. 


If the Directory tree supports multiple organizations that maintain 
distinct administration strategies or act as separate business units, you 
may want to create multiple Organization objects. 


For example, if the ACME Corporation functions as a single business 
unit and maintains the same general strategies for administration, 
access, and file system rights for the entire organization, create a single 
Organization object and name it ACME. 


If the ACME Corporation functions as two distinct business units 
without common rights or access between the general business 
headquarters and the manufacturing headquarters in Europe, create 
two Organization objects named ACME and ACME_EURO. 


The following figure illustrates how to use two Organizational object 
containers. 
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Figure 3-2 
Directory Tree Design with Single and 
Multiple Organizational Object Containers 


Single Organization 


ACMECORP 








(OU)=NEW YORK (OU)=ASIA 
(OU)=DETROIT (OU)=EUROPE 





Multiple Organizations 


ACMECORP 









(OU)=NEW YORK 
(OU)=DETROIT (OU)=ATLANTA 


(O)=ACME_EURO 


(OU)=FRANCE (OU)=GERMANY 
(OU)=SPAIN 









Use a name representative of the organization for naming the 
Organization object. Once you establish an Organization object name, 
consider registering the name with either the Internet or ANSI to enable 
future X.500 multiple tree and multiple name space operations. 


When naming an Organization object, use short, concise names. Short 
names provide easy access to network resources and simple navigation 
throughout the tree. Creating short names also reduces the likelihood of 
mistyping names. 


Forming Regional and Location Layers 


The upper layers of the Directory tree are most affected by the 
geographical and physical structure of your network environment. 


Because of this, you should structure the upper layers of your Directory 


tree to represent the major geographical locations in your organization 
and the network’s hardware, communication links, and LAN/WAN 
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topology. Doing this allows you to scale the Directory database 
according to the network’s WAN structures. 


The following table describes how to use Organizational Unit objects to 
represent a region-based and/or location-based structure of your 
organization’s geographical network. 


Type 


Purpose 





Location- 
based 


Use the geographical locations within your organization’s 
physical network infrastructure for naming location-based 
Organizational Unit objects. 


For example, if you have departments in different parts of a 
region, city, or campus, you could create SUC, SND, SFO 

containers, NORTH, SOUTH, EAST, WEST containers, or 
BUILD1, BUILD2, LIBRARY, HQ. 


Place the locational Organizational Unit objects directly 
under the Organization object layer. 


The locations should be geographical sites that have 
multiple departments or divisions included at each site. If the 
locations are small remote offices or field offices, you should 
place locational objects for those offices under an 
Organizational Unit object at a lower layer in the tree. See 
“Designing Lower Layers” on page 62 for more information. 
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Type 


Purpose 





Region-based 


Complex networks with multiple campus sites contained 
within a specific region should maintain a layer of region- 
based Organizational Unit objects above the location-based 
Organizational Unit objects. The network is easier to 
administer if the organization has regional offices that each 
manage a number of locations. 


For example, if you have divisions in three parts of a country 
and multiple departments in each part, you could create a 
WEST, MID, and EAST containers to contain individual 
groups of location-based containers, such as SJC, SND, 
SFO. 


Designing your tree according to the geographical 
structures of your organization also provides a more intuitive 
interface to the Directory tree. Users at a specific location 
can identify their location (or context) in the Directory tree by 
the location, or city that they work in. 


Organizing upper layers of the tree by the geographical 
structures in your organization also makes it easier for users 
to remember where their commonly-accessed network 
resources are. 


It also provides better organization for storing information 
and applications in your environment. 





environment with fast WAN links (T1 or better) and have no future plans for 


“yr If you are designing a tree for a single site or a single or multiple campus 
\4 


expanding to other locations, you won’t have issues concerning the 
geographical or physical network structure. Go to “Designing Lower Layers” on 
page 62 to continue. 


The following figures illustrate how to design a Directory tree 
according to your organization’s geographical structure. 
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Figure 3-3 
Physical Map of an Organizational Structure 
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Figure 3-4 
Example of Region-based Tree Design 
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Novell Directory Services is designed to operate in a fairly stable 
networking environment. The Directory tree design should account for 
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any intermittent links, on-demand links, or WAN links with minimal 
available bandwidth that exist in the network. 


When designing for particular LAN/WAN topologies, consider the 
following factors: 


@ Bandwidth 
% Speed 
% Cost 


% Regulations 


Designing Lower Layers 


The lower tree layers provide a high level of flexibility to support any 
layout that suits your environment needs. 


The lower layers include the following objects: 
@ Second and subsequent layers of Organizational Unit objects 
@ Leaf objects 
These layers are built upon the foundation established in the upper 
layers. They provide the logical divisions of network resources and 
lower level organizational structures that exist in your organization. 


Most objects in your tree will be in these layers. 


The most helpful documents for this task are organization and resource 
charts. 
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Determining the Directory Tree Framework 


Figure 3-5 

Lower Layer of a 
Simple Directory 
Tree 


The general framework of the Directory tree is established through the 
Organizational Unit objects that represent the logical divisions, 
departments, and workgroups in your organization. 


Organizational Unit objects help you to organize lower layer containers 
and other objects in the Directory tree. They also allow you to establish 
system-level login scripts and to create a template for User objects. 


Lower layers should be designed for naming and organizing network 
resources and not for creating consistent subtrees or container 


structures within your tree. 


The following two figures illustrate how container objects can be used 
to design the lower layers of your Directory tree structure. 


[ROOT] 
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Figure 3-6 
Lower Layer of a Complex Directory Tree 


Single Organization 
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Forming Containers Based on Common Access 


The most important consideration when structuring the lower layers is 
to create containers for network resources that have common access 

needs to other Directory objects. This allows you to make single trustee 
assignments or administer a single system login script for many users. 


Use an organizational chart to provide the logical structure for 
container names. 


Individuals in your organization chart should not be included in the 
tree as Organizational Unit objects. Container objects should also not be 
created as placeholders. Each container should only be created for 
existing functional groups and resources within the organization. 


Use Organizational Unit objects to represent functional groups as 


container objects. Place these containers directly under the location- 
based Organizational Unit objects or under the Organization object 
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depending on how many geographical locations exist in your 
organization. 


See Chapter 6, “Creating an Accessibility Plan,” on page 125 for more 
information. 


Forming Containers Based on Workflow 


Identify the workflow of your organization to determine possible 
groupings of individuals and services based on tasks rather than 
departmental lines. 


If your organization maintains long-term projects or is highly process- 
oriented, you might create container objects. 


Use Organizational Unit objects to represent the projects or products as 
container objects. Place these containers under Organizational Unit 
objects in a division or department. These types of containers are 
usually created at the lowest layers within the tree. 


Use a project resource chart relying on project names to provide the 
logical structure for container names. 


Individuals in your project chart should not be included in the tree as 
Organizational Unit objects. Container objects should also not be 
created for short-term projects or as place holders for future projects. 
Each container should only be created for project teams or production 
groups that access and use similar resources in the organization. 


Forming Containers Based on Management Structures 


The administrative model used in your organization can affect the 
design of the lower tree layers. With NetWare 4™ software, you can 
centralize network administration so that a single person or small 
group of people control the entire network. 


You can also distribute administration so that many network 
supervisors throughout the organization control their own portion of 


the Directory tree. 


The following table describes the three types of administrative models 
that should be considered when designing the lower layers of the tree. 
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Administrative 
Model 


Action 





Centralized 


Decentralized 


Mixed 
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To provide for greater central administration of the network, 
design the tree with more layers of hierarchy for faster 
browsing. 


To provide for better local administration of the network, 
design the tree with separate container objects for each 
administrative area in the tree. 


To provide for mixed administration of the network, use a 
hybrid of both central and local administration. You should 
ensure, however, that lower layer containers are managed 
by local administrators and upper layers are administered at 
central sites. 


Forming Containers Based on Service Groups 


Use a service-oriented approach such that users of similar services are 
grouped together across departments or other boundaries. 


Incorporating Specific Design Elements 
Some specific design elements may exist for your network that affect 
the framework used in the lower layers of the Directory tree. These 
elements are: 
@ Database scalability (partitioning and replication) 
@ Number of objects 


@ Network infrastructure 


@ Tree depth and name length 


Database Partitioning and Replication 


To adequately scale the Directory database and distribute portions of it 
across multiple servers, you should ensure that at least one 
Organizational Unit object exists for each portion of the tree that you 
want to partition. 


Number of Objects 


Create separate containers if the number of objects for a given container 
exceeds 5,000 objects. This provides for easier administration and 
scalability. 


Network Infrastructure 
Create a container for remote sites with slow links that belong to a 
particular division or department. For example, objects that represent 


resources belonging to a field sales office should be separated into their 
own container. 


Tree Depth and Name Length 


An appropriate depth for your environment enables easier access and 
management. 
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The Directory tree should maintain a depth between four to eight 
layers. As the complexity of your environment increases, either in 
numbers of objects or in the number of locations under single 
management, the tree depth will usually increase to accommodate 
those conditions. 


You should also ensure that the accumulated name length from the 
lowest layer to the top of the tree ([Root] object) does not exceed 256 
characters. 


Limitation of DOS command line utilities impose a maximum name 
length of 255 characters. When shorter Organizational Unit names are 
used, a deeper tree may be designed. However, the greater the depth of 
the tree, the more complex access to network resources may be. 


When objects are created, they are checked to ensure that the maximum 
name length of the object isn’t exceeded. However, it is possible to later 
rename an object and cause the name to exceed 255 characters. 


Reviewing the Directory Tree Structure 


As you draw (model) the Directory tree structure, also evaluate the tree 
design. Each member of the project team should have the opportunity 
to review the tree structure before continuing to the next procedure for 
placing network resources in containers. 


If you are upgrading from a NetWare 2 or NetWare 3™, you can use the 


Novell Directory Services migration utility to assist you in modeling 
your bindery data for migrating to the NetWare 4 Directory database. 
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Planning Placement of Network Resources 


Intuitive, quick, and secure access is the most important factor in 
determining where network resources should be placed in the 
Directory tree. To ensure that you identify the most efficient placement 
of network resources, you should 


e Establish consistent patterns for ensuring that objects reside near 
the resources that access them. 


% Create processes to ensure that network administrators provide 
the same accessibility and security for all objects in the tree. 


@ Develop a clear and concise blueprint for completing the 
implementation process. 


Place network resources in your tree structure by actually drawing each 
object in the container that it will reside in. 


The most helpful documents for this procedure are the Directory tree 
structure drawing, resource charts, and administration maps. 


Identifying Leaf Object Types 


y 
v 


The network resources that are used in your organization are 
represented by objects called leaf objects. 


Leaf objects are objects that do not contain any other objects. These 
commonly represent actual network entities such as users, servers, 
printers, and computers. You create leaf objects within a container 
object. 


If you are upgrading from a previous version of NetWare or migrating from a 
different operating system, the installation or migration utilities will identify many 
of the objects for you and place them in the container representing the server 
they were located on. 


The following table lists the current set of leaf object types available in 


NetWare 4. You should review the list to identify which object types you 
can create from the base set of objects. 
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Table 3-2 


Available Leaf Objects 











Leaf Object Description When to Use 
AFP Server Represents an AppleTalk* Filing Protocol- Create this object when you have an AFP 
based server that is operating as anode server on the network. Use it to store 

on your NetWare network (and possibly information about this server, such as its 

also acting as a NetWare router to, and description, location, and network address. 

the AppleTalk server for, several Apple* 

Macintosh* workstations). This object has no effect on the operation of 
the network; it only stores information about 
the AFP server. 

Alias Points to another object in the Directory Use this object to allow access to an object 


tree and makes it appear as if the object 
that it points to actually exists in the 
Directory tree where the Alias object is. 


Although an object appears both where it 
was actually created and where an Alias 
referring to it was created, only one copy 
of the object really exists. 


If you delete or rename an Alias, the Alias 
itself (not the object it is pointing to) is 
deleted or renamed. 


that is in another context. 


For example, you can use an Alias to 
represent a resource, such as a special 
printer, that most users in the tree need to 
access. 


Also, when you move or rename a container 
object in a Directory tree, you have the 
option of creating an Alias object in place of 
the moved or renamed object. If you select 
this option, NetWare Administrator 
automatically creates the Alias for you and 
assigns it the same name as the original 
object. 


Creating an Alias object in place of a moved 
or renamed container object allows users to 
continue logging into the network and to see 
the container object (and the objects it 
contains) in its original Directory location. 
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Table 3-2 


Available Leaf Objects 














Leaf Object Description When to Use 

Application NetWare Application Manager allows Application objects allow you to manage the 
network supervisors to manage network network more efficiently, saving time and 
applications as Application objects inthe effort administering applications. 

Novell Directory tree. 
Application objects simplify administrative 
NetWare Application Manager displays tasks such as assigning rights, customizing 
icons for all available applications in a login scripts, and supporting applications. 
window, and lets the user select an icon to 
launch an application. Users don't need to 
worry about drive mappings, paths, or 
rights. 
The network supervisor can manage 
applications at the container, Group, or 
User object level. 

Auditing File The Auditing File Object (AFO) is the An audit utility (such as AUDITCON) 
Novell Directory Services data structure creates the AFO when you enable auditing. 
used to manage an audit trail's The server then checks for access rights 
configuration and access rights. each time a user attempts to access the 

audit trail. 

Computer Represents a nonserver computer onthe Use this object to store information about a 


network, such as a workstation or a router. 


nonserver computer, such as its network 
address, serial number, or person the 
computer is assigned to. 


This object has no effect on the operation of 
the network; it only stores information about 
the computer. 
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Table 3-2 


Available Leaf Objects 





Leaf Object 


Description 


When to Use 





Directory Map 


Represents a particular directory in the file 
system. Directory Map objects can be 
especially useful in login scripts by 
pointing to directories that contain 


applications or other frequently used files. 


For example, if you have a directory that 
contains DOS 6.0, you will probably map 
a search drive to that directory in any login 
scripts you create. Later, if you upgrade to 
DOS 6.2 and rename the directory, you 
have to change the mapping in every login 
script where that search mapping 
appears. 


If you use a Directory Map object, you only 
change the information in that object, not 
in all login scripts. 


Use this object to avoid making changes to 
many login scripts when the location of 
applications changes; instead, you change 
only the Directory Map object. 





Distribution 
List 


Represents a list of mail recipients. 


Use this object to simplify sending mail to 
recipients. 


For example, you could create a Distribution 
List object called Recreation Committee. 
Anyone wanting to send a message to all 
the members in the Recreation Committee 
can simply address the message to 
Recreation Committee, rather than to each 
member. 





External Entity 


Represents a non-native NDS object that 


is imported into NDS or registered in NDS. 


NetWare MHS™ Services use External 
Entity objects to represent users from 
non-NDS directories to provide an 


integrated address book for sending mail. 


MHS Services software is available on 
NetWire. 


If your messaging environment contains 
non-MHS servers, such as SMTP hosts, 
SNADS nodes, or X.400 MTAs, you might 
choose to add users and lists at these 
servers to your NetWare database as 
External Entities. 


Adding these objects to the database as 
External Entities adds them to the address 
books of your messaging applications. 
When addressing messages, local users 
can choose non-MHS users and lists from a 
directory list. 
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Table 3-2 


Available Leaf Objects 














Leaf Object Description When to Use 
Group Assigns a name to a list of User objects Create a Group when you have many User 
that can be located anywhere in the objects that need the same trustee 
Directory tree. assignments. Rather than making many 
trustee assignments, you make just one 
trustee assignment to all the users who 
belong to the group by making the trustee 
assignment to the Group object itself. 
LSP Server When you register an LSP (License A client-specific component packages the 
Service Provider) with NDS, an LSP request and submits it to the nearest 
Server object is created, by default, inthe connected LSP. 
same context as the NetWare Server 
object on which it is loaded. The LSP If the client is not connected to an LSP, the 
Server object can be relocated to another Client checks the Novell Directory database, 
context in the Directory. searching up the Directory tree for an LSP 
Server object. 
An LSP Server object appears only if you 
load the NLS (NetWare Licensing 
Services) NLM program with an -r option. 
Message Represents a group of messaging servers Create a Message Routing Group when you 


Routing Group 


that can transfer messages directly with 
each other. 


have two or more messaging servers that 
need to communicate with each other. 





Messaging 
Server 


Represents a messaging server that 
resides on a NetWare server. A 
Messaging Server object is automatically 
created in the Directory tree when you 
install NetWare MHS Services on a 
NetWare server. 


MHS Services software is available on 
NetWire. 


Create a Messaging Server (by installing 
NetWare MHS Services on a NetWare 
server) when you need a server to handle 
messaging between users and groups on 
the network. 
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Table 3-2 


Available Leaf Objects 








Leaf Object Description When to Use 
NetWare Represents a server running NetWare. Use the NetWare Server object to tie the 
Server physical server to the Directory tree. 


Store information about the server in the 
NetWare Server object’s properties, such 
as the server’s address, the physical 
location of the server, and what services it 
provides. 


In addition to storing information about the 
NetWare server, the NetWare Server 
object affects the network in that it is 
referred to by several other objects. 


Without this object, you cannot access file 
systems that are on that server’s volumes. 


If you have a non-NetWare 4 server, you 
must create this object to be able to access 
those non-NetWare 4 volumes. When you 
create a NetWare Server object for a non- 
NetWare 4 server, the non-NetWare 4 
server must be running. 





Organizational 
Role 


Defines a position or role within an 
organization. 


Create an Organizational Role object so 
that you can assign rights to a particular 
position rather than to the person who may 
occupy that position. The occupant may 
change frequently, but the responsibilities of 
that position do not. 


You can assign any user to be an occupant 
of the Organizational Role object because 
every occupant receives the same rights 
that you granted to the Organizational Role 
object. 





Print Queue 


Represents a print queue on the network. 


You must create a Print Queue object for 
every print queue on the network. 


This object cannot be created with 
NETADMIN. Use the NetWare 
Administrator or PCONSOLE. 





Print Server 


Represents a network print server. 


You must create a Print Server object for 
every print server on the network. 


This object cannot be created with 
NETADMIN. Use NetWare Administrator or 
PCONSOLE. 
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Table 3-2 


Available Leaf Objects 














Leaf Object Description When to Use 

Printer Represents a physical printing device on You must create a Printer object for every 
the network. printer on the network. 

This object cannot be created with 
NETADMIN. Use NetWare Administrator or 
PCONSOLE. 

Profile Contains a profile login script. When the Create a Profile object for a set of users who 
Profile object is listed as a User object’s need to share common login script 
property, the Profile object’s login script is commands but who are not located in the 
executed when that User object logs in. same container in the Directory tree, or who 
The Profile login script executes after the are a subset of users in the same container. 
profile login script and before the user 
login script. 

User Represents a person who uses your You must create a User object for every 


network. 


In the User object properties, you can set 
login restrictions, intruder detection limits, 
password and password restrictions, 
security equivalences, etc. 


user who needs to log in to the network. 
When you create a User object, you can 
create a home directory for that user. When 
you create User objects, you can also 
choose to apply a template to the User 
object that provides default property values. 


For users who have NetWare 4 
workstations, you can create the User 
objects anywhere in the Directory tree, but 
the users must know their context in order to 
log in. You should create User objects in the 
container where the users will typically log 
in. 


For users who have non-NetWare 4 
workstations, you must create the User 
objects in the container where the bindery 
services context is set for the server that 
they need to log in to. (Bindery services is 
set by default for every NetWare 4 server 
that is installed.) Non-NetWare 4 users do 
not need to know their context because they 
log in to the server rather than to the 
Directory tree. 
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Table 3-2 
Available Leaf Objects 








Leaf Object Description When to Use 
Volume Represents a physical volume on the You can create a Volume object for every 
network. physical volume on the network. (During 


In the Volume object's properties, you can 
enter identification information, such as 
the Host server, volume location, etc. You 
can also set restrictions for use of the 
volume, such as space limits for users. 





installation of NetWare 4 on a server, 
Volume objects are created for every 
physical volume on that server.) 


Use INSTALL to create volumes on 
NetWare 4 servers. 


When a Volume object is created, the server 
name and the volume name information is 
placed in the Volume object's properties. 


You can use the Volume object to display 
information about the directories and files 
on that volume. 


NetWare Message Handling Service (NetWare MHS) objects. They appear in 


y The Message Routing Group, External Entity, and Distribution List objects are 
v 


NetWare Administrator only if you have installed NetWare MHS Services on 


your NetWare servers. 
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Determining Leaf Object Placement 


Determining where to place leaf objects in the tree depends on the 
container structure that was established. It may be necessary to change 
the container structure to accommodate some objects within your tree. 


The following figures illustrate how leaf objects can be placed in the 
Directory tree structure. 
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Figure 3-8 


Example of Leaf Objects in a Complex Tree 
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Placing Shared Resources 


Place shared leaf objects in the lowest container level that incorporates 
all the objects which need access to it. 


For example, if a printer is used by two different departments which 
have separate Organizational Unit containers, place the Printer object a 
level above the two Organizational Unit containers for those 
departments. 


Placing Server Objects 


NetWare Server objects must be in or under the container that 
represents the physical location of the NetWare 4 server. 


Place NetWare Server objects in the same container that contains the 
objects that access the server. For example, all User objects, services, 
print queues, and other leaf objects in the tree that attach to or are stored 
on a given server should reside in the same container. 


You should also determine where to place central group servers such as 
e-mail and public servers. When considering where to place common 
servers, consider the amount of network traffic that will be generated 
on the wire and where users will find the server easily. Use Alias objects 
for these common servers to allow users easier access to them. 


Designing for environment-wide aliases should be done when 
determining where to place common servers and resources. 


Placing Objects for Mobile Users 


Place Directory Map objects consistently throughout the tree to allow 
users to map a drive easily to a local server to access applications from 
any point in the Directory tree. This approach requires that some 
servers in the Directory tree maintain identical file system structures. 


Place an Alias object of servers that mobile users commonly access close 
to the [Root] of the tree to make the authentication process faster. 


Placing Objects for Global Resources 
If an environment has many globally shared resources, design the tree 


to accommodate those resources. The following actions make the 
network more usable: 
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Summary 


When a user authenticates to the network, the profiles and scripts 
for that user are executed. If any of those are not kept locally, the 
login process retrieves those profiles and scripts across the LAN or 
WAN. 


Keep the profiles and scripts either on the same server that the 
user’s home directory is located on or relatively close to the user 
across fast LAN or WAN links. This will decrease the time for the 
user during the authentication process. 


When a global application that needs access to the entire tree such 
as e-mail or calendars relies upon the Directory database, build a 
branch of the tree that contains Alias objects to the real objects. 


This could be a single container just off of the [Root] object or a 
hierarchial subtree built directly below the [Root] object that 
contains an Alias object for every object that might be needed for 
the application. 


After you have considered all the factors that will affect your tree 
design, lay out the final draft of your tree with a modeling or drawing 
application or diagram it on paper. 


Remember that Novell Directory Services supports a high level of 
design flexibility. If you later want to change the layout, you can do it 
easily with the NetWare 4 utilities. 
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Evaluation 


Once you have completed your design, review the following questions 
to evaluate the efficiency of your tree design: 


+ 


What logical structure of the Directory tree makes the most sense 
for the physical layout of your network? 


What organizational structure of the Directory tree makes the 
most sense for your network resources? 


How can resources be distributed across the network to reduce 
line traffic but still provide easy access for workgroups, users, and 


applications? 


How do you want the Directory database to be partitioned, and 
where do you want to store replicas of those partitions? 


How will your tree design affect the length and format of object 
names? 


How does your tree design support designing other services such 
as printing and security? 


How easily can this tree merge with other trees? 
Does this tree design allow for future growth? 


Does this tree provide efficient accessibility and navigation for 
local, global, and mobile users? 


Chapter 3: Designing the Directory Tree Structure 81 


Defaults 


The default settings for Directory objects are as follows: 





Default Objects after NetWare 4.11 
Installation 


Default Objects after NetWare 4.11 
Upgrade 





NetWare Server object for the server 


on which NetWare 4.11 was installed. 


NetWare Server object for the server 
you upgraded to NetWare 4.11. 





Volume object SYS. 


Volume object SYS for volume SYS: 
on the server you upgraded. 





Volume objects for any other volumes 
besides SYS: that you created during 
installation. 


Volume objects for every other 
volume besides SYS: on the server 
you upgraded. 





User object ADMIN. 


When User object ADMIN is first 
created, by default it is placed in the 
Organization container object. This 
may not be the same context in which 
you installed the server. 
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User object ADMIN. 


When User object ADMIN is first 
created, by default it is placed in the 
Organization container object. This 
may not be the same context in which 
you installed the server. 


All other objects that were on the 
server's bindery are placed in the 
same container as the server that 
was upgraded. 





y The upgrade utility converts most existing bindery objects to NDS objects. 
v 





Where to Go from Here 


To Go to 





Determine the strategy you will use to Chapter 4, “Determining a Partition 


scale and distribute the Directory and Replication Strategy,” on page 85 
database to servers throughout the 

network 

Plan the approach you will use to Chapter 5, “Planning the Time 


maintain a consistent network time for Synchronization Strategy,” on 
servers and clients on the network page 107 


Create an accessibility plan for Chapter 6, “Creating an Accessibility 
determining how network resources Plan,” on page 125 

are accessed and used on the 

network 


Chapter 3: Designing the Directory Tree Structure 83 


84 Place Book Title Here 


chapter 4 


Introduction 


Determining a Partition and 
Replication Strategy 


This chapter describes how to determine the partition strategy on your 
network. The following topics are discussed: 


@ “Forming Partition Boundaries” on page 88 

@ “Determining an Efficient Replica Placement Strategy” on page 93 
If you have a single server environment, you do not need to determine 
a partition strategy. Continue with Chapter 5, “Planning the Time 
Synchronization Strategy,” on page 107. 


Multiserver networks that meet the following conditions should accept 
all partition and replica defaults provided in NetWare® 4™: 


@ No WAN links 
@ No more than 15 servers 
@ Fewer than 1,000 objects 


See “Defaults” on page 104 for more information. 


Directory objects and their attributes exist in a database that is 
maintained and managed by Novell® Directory Services™ (NDS™). 
NDS distributes information about each Directory object to servers 
throughout the network. 


NDS does this by dividing the database into logical segments of the 
Directory tree, and then copying each logical segment to a group of 
servers on the network. This logical segmenting is referred to as 
partitioning. The process of copying each logical segment to servers is 
referred to as replication. 
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Objectives 


Prerequisites 


Although partitioning and replicating the database means that not all of 
the Directory database information exists on each server throughout the 
network, links are established between servers to allow access to all of 
the database information. This does not mean, however, that every 
server on the network holds partition replicas. NetWare 4 utilities 
manage and monitor the partitioning process and the links between 
servers. 


When determining the partition strategy, it is important to remember 
that partitioning is simply the logical segmenting of the Directory 
database, whereas replication is the physical placement of a partition on 
servers throughout the network. This means that you should consider 
not only the Directory tree structure but the physical network 
infrastructure. 


You should also determine a partition strategy that provides the most 
effective placing of replicas without high management overhead or 
increased network traffic. 


You should determine a partition strategy for your network by forming 
partition boundaries and effectively placing replicas. 


Use resource maps, location maps, LAN and WAN topology maps, the 
Directory tree structure, and partitioning guidelines to determine the 
partition boundaries and what types of replicas to store on which 
servers in the network. 


A VÁ l] You should have copies of the following planning documents: 


+ WAN topology maps 
Location maps 
Resource maps 
Directory tree structure 


+ ©% . + 


Partitioning guidelines 


l] You should have completed your Directory tree design. See 
Chapter 3, “Designing the Directory Tree Structure,” on page 39 
for more information. 


86 Place Book Title Here 


Determining Partition Requirements 


Partitions should only be created to 


+ 


4 


+ 


+ 


Reduce the dependency on a single network server 
Reduce the size of the database for any single sever 

Place resources near users for performance improvements 
Reduce network wire traffic caused by user access 

Reduce network traffic due to the synchronization process 


Decrease the administrative overhead 


Avoid partitioning if it 


+ 


+ 


+ 


+ 


Causes administrative overhead 


Creates additional subordinate references for the child and parent 
partitions 


Increases network complexity 
Increases the time needed to navigate the tree 


Produces minor increases in network wire traffic 


You need to determine the best balance of advantages and 
disadvantages before creating a partition strategy for your tree design. 
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Forming Partition Boundaries 


Forming effective partition boundaries enables you to scale and 
optimize the Directory database on your network. To do this, you 
should understand some basic characteristics of partitions. 


Considering Partition Characteristics 


A partition is a subtree or branch of the Directory tree. Each partition is 
named according to the partition root object. This is the highest container 
object in the partition. This container is also referred to as the partition 
root entry. 


The [Root] object is always included in the first partition created, which 
is known as the [Root] partition. 


When a partition is subordinate to another in the Directory tree, it is 
referred to as a child partition. The partition above it is referred to as the 


parent partition. 


The following illustration shows a parent partition in relation to its 
child partition in a Directory tree. 
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Partitions must follow a strict set of rules. These rules are as follows: 


Figure 4-1 
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% A partition can contain only Directory objects and related data. It 
cannot include any information about the file system directories 
and files. 


% A Directory object can exist in only one partition. 


@ Partitions can be stored only on NetWare 4 servers. 
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% Partitions cannot overlap each other. 


@ Partitions must contain a connected subtree. 


Planning the Partition Layout 


When the first server of a Directory tree is installed, a partition is 
created at the [Root] object. This partition is referred to as the [Root] 
partition and contains the entire Directory tree at that time. 


The [Root] partition is the only partition that the installation process 
creates. All other partitions must be created manually. 


The design of your partitions should resemble a triangle with a small 
number of partitions at the top level of the tree and more partitions as 
you move toward the bottom. Such a design will create fewer 
subordinate references than a tree that has more partitions at the top 
than at the bottom. 


This triangular design can be accomplished if you always create the 
partitions relatively close to the leaf objects (particularly the users). An 
exception is the [Root] partition. 


Designing Partition Boundaries 


In most cases, you should design partition boundaries around the 
physical layout of your network infrastructure. This coincides very well 
with the approach used in designing the upper and lower layers of the 
Directory tree. 


As a rule, if your tree design is structured correctly, your partition 
strategy will be easy to implement and maintain. Consider the 
following guidelines when partitioning the Directory tree: 


@ Design upper layer partitions around Organizational Unit 
boundaries that represent location or organizational structures. 


% Plan the partitioning so that partitions contain objects from a 
single campus. Do not allow partitions to span slow WAN links. 


A single campus consists of a single location or multiple locations 
connected by high speed (T1 or better) WAN links. 
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A VÁ 


Subordinate reference replicas will exist across WAN links if no 
partitions are spanned across WAN links. Ensure that your 
strategy creates a balance between maintaining local partitions 
and reducing the number of subordinate reference replicas that 
are created. 


Also consider NDS backup issues when creating local partitions. 
If you plan to regularly back up the entire tree from a central 
location, consider the amount of time it may require if information 
needs to cross WAN links. 


% After installing the first NetWare 4 server, use NDS Manager or 
PARTMGER to create partitions before installing subsequent 
network servers. 


One approach that has been used successfully and reduces the amount 
of manual partition placement is to partition the tree first and then add 
additional servers into the tree for each partition. 


% Maintain small partitions. 


@ Place partitions near the Directory objects (particularly User 
objects) that use the resource contained within the partition. 


% Group servers on the same cabling segment into the same 
partition if you split partitions because of any the following 
conditions: 


+ WAN links exist 
+ More than five servers exist in a partition 


+ More than 1,000 objects exist in a partition 


Designing Partitions for Upper Layers 


The first layer of partitions after the [Root] partition is defined 
according to the physical locations within your organization and the 
network infrastructure. For example, if your organization has multiple 
campus sites located across the country, your tree design should reflect 
this geographical separation. Upper layer partitions should be 
established at each of these individual sites. 


If your organization is contained at a single site, your upper layer 
partitions should reflect the organizational structure of the upper 
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layers. Partitioning at a single campus site, however, is more dependent 
on the number of objects within a branch of containers than the physical 
infrastructure. This is because no slow WAN links exist. 


If WAN bandwidth is an issue, create smaller partitions and replicate 
them in fewer locations with fewer subordinate partitions. This 
produces less network traffic when synchronizing across WAN links. 


Designing Lower Layer Partitions 


Lower layer partitions are defined according to the organizational 
divisions within the organization and how they are reflected in the tree 
design. The Directory tree design should identify division, department, 
and workgroup structures within an organization. Partitioning should 
be patterned along these same lines. 


Determining the Size and Number of Partitions 
The size of the partitions can significantly affect the synchronization 
and responsiveness of the system. As you plan partitions, you should 
balance the factors concerned with its size. 
You should consider the following: 
% Partitions that contain more than 1,000 objects will cause long 
delays in synchronization and high levels of network traffic 


depending on the network hardware used. 


% Partitions that contain fewer than 50 objects may cause more 
management overhead than their worth. 


% A tree design that contains many slow WAN links may require 
additional partitions. 


% Your administrative model may require more partitions at the 
lower level to better define areas of management and control. 


@ The amount of network traffic your network can support will 
affect the number of partitions. 


@ The static nature of objects in the tree may determine the number 
of partitions. If your network is rapidly growing, you should 
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oy 
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allow for future growth by maintaining relatively small partitions. 
Nevertheless, splitting or joining partitions is a simple task. 


If you maintain large partitions, performing partition operations will be time 
consuming if network throughput is slow and a large number of objects 
are being affected. 


Determining an Efficient Replica Placement Strategy 


Determining the most effective replica placement strategy allows you to 
optimize the Directory database for fault tolerance, accessibility, and 
navigation. To do this, you should understand some basic 
characteristics of replicas. 


Considering Replica Characteristics 


A replica is basically a physical copy of a partition. An unlimited 
number of replicas for each partition can be stored on any NetWare 4 
server on the network. Also, a single NetWare 4 server can store 
multiple replicas if they are generated from unique partitions. 


Basic Functions of Replicas 


oy 


Replicas provide the following three functions to the network: 


+ 


Directory fault tolerance. If a disk crashes or a server goes down, 
a replica on a server in another location can still authenticate users 
to the network and provide information on objects in the disabled 
server’s replica. 


With the same information distributed on several servers, clients 
are not dependent on any single server for network authentication 
or to provide services. 


If your network has only one server, you will most likely maintain only a 
single copy of the [Root] partition. This is because your network 
infrastructure doesn’t require it. 


Under this scenario, the only means of providing some level of fault 
tolerance is by maintaining a up-to-date backup copy of the Directory 
database. Make sure that your backup software can back up NDS. 
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Partition replication does not provide fault tolerance for the file system. 
Only information about Directory objects is replicated. To provide fault 
tolerance for your files, you must mirror or duplex your hard disks and 
enable the Transaction Tracking System™ (TTS™) feature. 


Increased access performance. Distributing specific Directory 
information to servers that are physically near workgroups or 
users who frequently access the information greatly increase the 
performance of authentications, modifications, and searches. This 
is because information is retrieved from the nearest available 
server containing the specified information. 


Access to information that exists in partitions across WAN links is 
improved and WAN traffic is decreased, depending on the 
amount of synchronization that is required. 


Tree walking. Finding specific information in the Directory tree is 
referred to as tree walking, or name resolution. This technology 
allows clients to locate Directory information that doesn’t exist 
within the container their User object resides in. NDS performs 
the name resolution process to locate the information. 


Every replica maintains references (pointers) to servers that store 
those replicas that are subordinate or superior to its relative 
position in the Directory tree. NDS uses these pointers to walk up 
or down the tree to find the information that is requested. 


Placing replicas of frequently accessed information on local 
servers increases the speed at which names are resolved. 


Identifying the Four Types of Replicas 


There are four types of replicas. 


+ 
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Master replica. A master replica is a writable replica that contains 
all object information for the partition. All partition operations 
(create, merge, move, delete) occur from the master replica of the 
given partition. 


Only one master replica can be defined for each partition. 


Read/write replica. A read/write replica contains the same object 
information as the master replica. It allows modifications (writes) 
when a master replica of the given partition is already defined 
somewhere else. 


y 
\4 


There can be any number of read/write replicas. 


Client workstations can update master and read/write replicas 
only. 


@ Read-only replica. A read-only replica contains the same object 
information as the partition, but the information can only be read. 
It is used where reading the partition is required, but writes to the 
partition should not occur. 


A read-only replica cannot be used on a server where bindery services is 
required because bindery services requires a writable replica. When 
bindery services is set, use either a master or read/write replica. 


The default setting in the NetWare 4 installation program copies a 
read/write replica of the partition that a bindery server is being upgraded 
to. 


@ Subordinate reference replica. A subordinate reference replica 
cannot be modified by any user. It is automatically placed on a 
server by NDS if the parent partition has a master, read/write, or 
read-only replica on the server and the child partition does not 
exist on the server. 


If you add a read/write or read-only replica of the child partition 
to the server, the subordinate reference replica is removed. 


Network resources are held in the master, read/write and read-only 
replicas. Read-only replicas have limited scope and are not typically 
implemented. Subordinate reference replicas are automatically 
allocated and created, and tie the partitions of the tree together. 


Identifying How Replicas Are Updated and Synchronized 


When changes are made to objects within a partition, those changes are 
automatically sent to all other replicas of that partition. This ensures 
that the global Directory database remains consistent. Only changes are 
sent to other replicas. For example, if a user changes a phone number, 
only the new phone number is sent, not the entire User object. 


The master replica participates in the partition synchronization process 
by exchanging updates with other replicas but does not control this 
process. Similarly, each read/write replica synchronizes with the other 
replicas of the partition. Read-only replicas also synchronize with other 
replicas, but they receive updates only from other servers. 
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An NDS database is a “loosely consistent” database. As changes occur, 
all replicas of a partition do not always contain exactly the same 
information at every instant. In fact, the contents of the replicas most 
likely vary slightly at any given time. However, these replicas 
eventually converge to a consistent state once the changes are 
distributed to all replicas. 


Some changes are sent immediately to other replicas, such as changes 
to a user’s password. Less critical changes, such as a user’s last login 
time, are collected locally for a short period of time before being sent out 
to the network. 


For this synchronization to occur, each replica must be contacted. When 
a partition is created, some additional attributes are added to the 
container object that is acting as the partition root object. These 
properties are used to manage the synchronization of data between 
replicas of the partition. 


Three attributes should be considered when considering 
synchronization issues: 





Attribute Description 





Replica Pointer Each partition maintains a record of the location of each 
of its replicas. The locations are stored in the partition’s 
replica property, with one property entry for each 
replica of the partition. The collection of replica pointers 
of a partition forms a list of the partition’s replicas, 
sometimes called a replica ring or replica list. 


Synchronized Up To Each replica in the replica list for a partition maintains a 
list of time stamps. The server holding a particular 
replica uses this attribute to determine the 
synchronization state of the replica it’s holding in 
comparison to other replicas in the replica list. This 
attribute is sometimes called a vector of time stamps. 


Inherited Access The partition root object is responsible for determining 

Control List (ACL) the access rights inherited from the [Root] object down 
to itself. This attribute is primarily a summary of the 
ACL for all objects within its partition. 
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Planning Replica Placement 


Figure 4-2 
Example of [Root] 
Partition Placement 


When the first server of a Directory tree is installed, the first replica of 
the [Root] partition is placed on that server. This first server contains the 
master replica of the [Root] partition. 


There are no special rights or considerations for this server. The replica 
of [Root] can be removed at any time or changed to a read/write replica 


once other servers are in the tree. 


The following figure illustrates how the [Root] partition can be 
replicated on your network. 
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When you install additional servers in the tree, follow two simple rules 
to determine if a replica should be placed on the server. 


@ Ifyou are upgrading the server from Netware 3™ to Netware 4, a 
replica is placed on that server to support bindery services for up 
to three servers in a given partition. 


@ If fewer than three replicas of a given partition exist in the tree, a 
replica is placed on the server to provide for fault tolerance and 


disaster recovery. 


In all other cases, if a replica is desired on a server, the replica will have 
to be added manually. 


The following figure illustrates how replicas can be placed on server in 
the Directory tree. 
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Designing Replica Placement 


In most cases, you should design replica placement around the 
principles of fault tolerance, accessibility, and navigation. Consider the 
following guidelines: 


% Create a minimum of three replicas of each partition. 


@ Replicate the [Root] partition at least three times (this partition is 
required to maintain the integrity of the tree). The server 
installation program automatically creates one replica of the 
[Root] partition. Other replicas must be created manually. 


% Maintain performance by placing a replica containing information 
on a server that the users access (located within a single campus). 


% Create replicas as needed for bindery services. 


% Consider the NDS access performance goals, such as tree walking 
and keeping partitions and replicas close to the users. 


Placing Replicas for Fault Tolerance 


Create a minimum of three replicas of each partition. You may want to 
create more, depending on network topology or performance. 


Place at least one copy of each replica off site, in another building or 
location. You may want more locations, depending on the disaster 
recovery plan being used by the organization. You can rebuild most of 
the network by using partition replicas. 


Ensure that subordinate reference replicas are not used for fault 
tolerance. Subordinate reference replicas can be used to restore the tree 
structure, but not leaf objects. 


Placing Replicas for Accessibility 


Place replicas in the location of highest access. This means that if groups 
of users in two separate containers need access to the same object within 
another partition boundary, you should place the replica on a server 
that exists in the container one level above the two containers holding 
the groups. 
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Placing Replicas for Navigation 

Place replicas on servers that contain objects for users and resources 
that are physically near the server. This allows for faster response to 
users’ requests for login authentication and access to network 
resources. 

Place replicas on the server that stores the user’s HOME directories that 


access it. Also, store replicas of Directory objects that exist on opposite 
sides of a WAN link on the local servers that users access. 


Placing Replicas for Administration 
Partition operations require that a master replica of each partition be 


accessible. You should ensure that master replicas exist on servers that 
are located physically near the administrator of the partition. 


Placing Replicas for Bindery Services 


Bindery services is enabled at installation or is automatically enabled if 
you are upgrading a server from NetWare 2 or NetWare 3. 


If bindery services is enabled, the server receives a read / write replica of 
up to three partitions that contain a container object in its bindery 
context. 


Consider the following guidelines for bindery services support: 


1. Identify all containers that hold bindery resources and record 
their context. (This is referred to as bindery context.) 


2. Identify the partitions that hold the containers with bindery 
resources. 


3. Place a read/write replica of those partitions on the server. 


Placing Replicas for Servers 
Place as few replicas on a server as possible. 


Place replicas on the best servers in your network. Slow servers can 
affect the replica synchronization for all servers within the replica ring. 
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(The replica ring refers to the group of servers that hold replicas of the 
same partition.) 


Creating a Replication Matrix 


Summary 


You should create a replication matrix for your network. Use the 
following table to organize the physical placement of the replicas for 
each partition. We recommend that each partition have three replicas 
for fault tolerance, but you may need more replicas depending on user 
access. See “Template Examples” on page 277 for more information. 


Partitioning and replica placement allow you to scale your Directory 
tree to meet your organization’s needs. This process can be as simple as 
accepting all defaults or as complex as designing a partitioning and 
replica placement matrix to define many locations for your partitions 
and replicas. 


The following table list reviews some of the basic guidelines to follow 
when partitioning your Directory: 


Condition Guideline 





Location + In a network with WAN links, partitions should not span 
multiple locations 


+ Partition locally around the servers (keep physically 
distant servers in separate partitions) 


+ Place fewer partitions at the top of the tree with more at 
the bottom 


Size + Keep partition sizes small 
+ The [Root] partition should remain small 


+ Typically, a partition should have fewer than 1,000 
objects, and no more than 3,500 


+ Typically, a partition should have fewer than ten to 
fifteen subordinate partitions, and no more than forty 
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Evaluation 


The following table list reviews some of the basic guidelines to follow 
when placing replicas in your Directory: 


Condition Guideline 





Placement + Replicate locally, not across a WAN link (Replicas 


across a WAN link have to send/receive NDS 
synchonization information, which can slow down 
network traffic across a WAN link) 


+ |f possible, place master replicas physically close to the 
master of parent and child partitions 


Number + Always keep two or three replicas per partition, and no 


more than ten 


+ Never store more than ten replicas on a server 


Once you have completed your partition strategy, review the following 
questions to evaluate the efficiency of your strategy: 


+ 


Are the upper layer partitions formed around Organizational Unit 
container boundaries that represent location or organizational 
structures? 


Do partitions contain only objects from single campus or span 
high speed (T1 or better) WAN links? 


Do the partitions contain fewer than 1,000 objects? 


Are partitions located near the objects (particularly User objects) 
that use the resources contained within the partition? 


Are servers physically located on the same cabling segment 
grouped into the same partition? 


Is there a minimum of three replicas of each partition? 
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% Do replicas exist to support bindery services? 


% Are replicas stored on servers to meet your access performance 
goals, such as tree walking and keeping partitions and replicas 
close to the users? 


Defaults 


The defaults for partitioning and replication are as follows: 





Replica Type 


Default 





Master 


Read/write 


Read-only 


Subordinate 
reference 





104 Place Book Title Here 


The first NetWare 4 server in the network receives the 
master replica of the [Root] partition. 


The first server in a partition receives the master replica of 
that partition. 


New servers. The second and third servers in a partition 
receive read/write replicas of that partition. Subsequent 
servers receive no replicas unless bindery services is 
enabled at installation. 


If bindery services is enabled on the new server, the server 
receives a read/write replica of up to three partitions that 
have a container object in its bindery context. 


Upgraded server. A server upgraded from NetWare 2 or 
NetWare 3 receives a read/write replica of up to three 
partitions that have a container object in its bindery context. 


Note: Bindery services is enabled at installation or is 
automatically enabled if you are upgrading a server from 
NetWare 2 or NetWare 3. 


None. 


Subordinate reference replicas are automatically allocated 
and created, and tie the partitions of the tree together. 


Where to Go from Here 


To 





Go to 





Plan the approach you will use to 
maintain a consistent network time for 
servers and clients 


Create an accessibility plan for 
determining how network resources 
are accessed and used 


Create an application management 
strategy for network applications to 
improve and efficiently manage 
network applications 


Create a migration strategy for 
servers and workstations from a 
previous version of NetWare or other 
network operating system 


Create an implementation schedule 


Chapter 5, “Planning the Time 
Synchronization Strategy,” on 
page 107 


Chapter 6, “Creating an Accessibility 
Plan,” on page 125 


Chapter 8, “Designing an Application 
Management Strategy,” on page 179 


Chapter 9, “Developing a Migration 
Strategy,” on page 193 


Chapter 10, “Creating an 
Implementation Schedule,” on 
page 223 
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chapter 5 


Introduction 


Planning the Time Synchronization 
Strategy 


This chapter describes how to plan a time synchronization strategy. The 
following topics are discussed: 


@ “Determining an Efficient Time Synchronization Method” on 
page 109 


e “Identifying an Efficient Time Source and Configuration” on 
page 113 


If you have a single server environment, you do not need to plan for 
time synchronization. Continue to the next procedure. See Chapter 6, 
“Creating an Accessibility Plan,” on page 125 for more information. 


Multiserver networks that meet the following conditions should accept 
all time synchronization defaults provided in NetWare® 41M: 


@ No WAN links exist 

@ Fewer than thirty servers exist 

@ Single time zone exists 
See “Defaults” on page 122 for more information. You might also want 
to review information about using a combination of internal and 


external time synchronization methods. See “Using a Combination of 
Time Synchronization Methods” on page 112 for more information. 


Directory objects exist in a database that is maintained and managed by 
NetWare Directory Services™ (NDS™). The database can exist on a 
single server or can be partitioned and distributed as replicas on other 
servers. NDS ensures that when changes are made to objects in a 
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partition, the changes are made to all replicas of that partition in the 
proper order in which they were performed. 


If multiple events exist for a particular object within a partition, NDS 
checks that the events are made to the object in their proper sequence. 
An example of this would be one administrator renaming an object and 
another moving the object. If these events occurred out of sequence, the 
object might not be renamed because it would not exist in the original 
tree context. 


To ensure that events occur in their proper sequence, NDS records the 
time of each event relative to a common time source. This time record is 
referred to as a time stamp. NDS uses the time stamp to ensure that when 
it modifies the database, the particular event occurs in the time and 
order that it was intended. NDS also uses time stamps to record “real 
world” time values for the network and set expiration dates. 


In a single server environment, the servers internal clock is adequate to 
maintain a common and consistent time source for the network. 


In a multiple server environment, NetWare 4 includes functionality to 
maintain a common time for all NetWare 4 servers in the network. It is 
referred to as time synchronization. 


The common time source necessary for tracking the proper sequence of 
events is provided through time synchronization across all NetWare 4 
servers. You should plan your time synchronization strategy to ensure 
that a common time source is maintained efficiently and accurately. 


Note wava The standard format used for times and time offsets is [+|-] HH:MM:SS. In 
Y practice, only the significant portion of the time need be specified (+7:0:0 is the 
same as 7). 


In addition, the examples used in this chapter show the colon as a time 
separator. The actual character used as the time separator is determined by the 
country information for each server. In most instances in NetWare 4, input and 
output routines dealing with dates and times are language enabled to use the 
locally preferred format and characters. 
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Objectives 


Prerequisites 


The objective in planning the time synchronization strategy is to 
determine an efficient time synchronization method to use, and then 
identify the best way to set up and manage that method across the 
network. 


Use resource maps, location maps, LAN and WAN topology maps, and 
the tree design document to determine which time servers to use and 
what communication format to use between the network servers. 


A VÁ [1 You should have copies of the following planning documents: 


+ Resource maps 

+ Location maps 

+ LAN and WAN topology maps 
+ Directory tree design 


Determining an Efficient Time Synchronization Method 


NetWare 4 needs to maintain a correct system time (“real world” time) 
for keeping file date and time stamps correctly, for auditing and 
logging, and to manage user's login time restrictions. It is also 
important to maintain a common time for the entire network system of 
servers. 


Time synchronization provides mechanisms to adjust and compensate 
for the rate of the operating system software clock. In addition, it also 
provides support for Universal Time Coordinated (UTC) time, the 
worldwide time standard coordinated to the zero meridian (0ø of 
longitude, also known as (GMT) Greenwich Mean Time). 


This is done by designating one or a group of servers to act as the time 
source for all other servers and client workstations in the network. All 
other servers act as secondary time servers, receiving UTC values from 
the time source. This relationship ensures that any drifts between time 
settings of different server’s internal clocks are corrected and common 
time is maintained. 
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Establishing a common time source for the network can be done using 
one or a combination of the following two methods: 


@ Internal time synchronization 


@ External time synchronization 


Using Internal Time Synchronization Methods 


NetWare 4 provides you with the functionality to maintain the same 
UTC time on all servers. This is done through a server utility named 
TIMESYNC.NLM. TIMESYNC allows you to set up different types of 
time source servers that provide time to other servers and clients. 


Using TIMESYNC 


All NetWare 4 servers automatically load TIMESYNC, which manages 
the updating of each server’s Universal Coordinated Time (UTC) 
relative to the UTC of the network. Time synchronization is active 
whenever TIMESYNC is loaded. 


TIMESYNC determines if its internal clock coordinates with that of the 
time provider. This is done by determining if the internal clock time is 
synchronized within a specific time radius of the value received from 
the time provider. If the synchronization radius is within the set amount 
of time, the server sends a time synchronization flag to indicate that 
synchronization is established. 


The synchronization radius is set with TIMESYNC parameters in the 


SERVMAN or SET utilities. The default setting is 2000 milliseconds, or 
roughly 2 seconds. 


Identifying NetWare Time Servers 


The TIMESYNC utility allows you to set up four types of time servers 
in NetWare 4. See the following table for a listing and description. 
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Table 5-1 


Time Server Types 








Server Type Function Caution Description 
Secondary Receives time from a time You can have a Secondary Attempts to stay 
(Default) source server and provides time server contact another synchronized with one time 
time to client workstations. Secondary time server to source. 
obtain the correct time. 
Does not participate in 
However, if the intermediate voting. 
Secondary time server is ; 
unavailable, servers that Most servers will be 
contact it for the correct time Secondary servers. 
might be too many hops 
away from a time source 
server to get synchronized. 
Primary time Polls and votes with other Must be able to contact at Polls all other time sources 
server Primary time servers to least one other Primary time to determine correct 
determine time, and server or a Reference time network time and 
provides time to Secondary server. compensate for clock errors 
time servers and client 
workstations. Sets synchronization status 
based on its deviation from 
Use with Reference time calculated network time, 
servers to pass time to without regard to status of 
Secondary time servers and other time sources polled. 
client workstations. 
Single Provides time to Secondary All servers must be able to Functions the same as 
Reference time servers and client contact the Single Reference time server, 
time server workstations. Typically used Reference time server. No however it does not 
for smaller LANs. Primary or Reference time synchronize with any other 
servers can be on the server. 
network. 
Reference Receives time from an Typically, only one Functions the same as a 
time server external time source and Reference time server is Primary time server, except 





provides time to Primary and 
Secondary time servers. 


Use when it is important to 
have a central point of 
control for time on the 
network. 


installed on a network. If 
there is more than one 
Reference time server, each 
must be synchronized with 
the same external time 
source. 


that it does not adjust its 
internal clock. 


Provides a central point of 
time control for the entire 
network. 
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Each time-synchronized server performs three fundamental functions: 


@ Provides UTC time to any NLM or client workstation that 
requests it 


@ Provides status information indicating whether the UTC time is 
synchronized 


% Adjusts its internal clock rate to correct for drift and maintain UTC 
synchronization 


See “Identifying an Efficient Time Source and Configuration” on 
page 113 for more information. 


Using External Time Synchronization Methods 


Common time can be established by connecting all network servers to 
the same external time source. Depending on the cost of the source or 
hardware setup, this can be an effective method for maintaining 
common time on your network. 


Some examples of external time source are radio clocks, atomic clocks, 
or Internet time. 


Using a Combination of Time Synchronization Methods 


Time synchronization services does not attempt to provide correct time 
of day to the servers. It can only keep the internal clocks of each server 
set to a common time. 


You can ensure the accuracy of your network’s time of day by simply 
checking the time provider’s Universal Coordinated Time (UTC) value 
against a wristwatch, or by attaching the time provider to an external 
time source service through a modem, radio, or Internet time source. 


Note Var Adjust the synchronization radius if the time provider servers are separated by 
WAN or satellite links that cause delays in packet transmissions. 
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Identifying an 


Efficient Time Source and Configuration 


Identifying the best time source and configuration for your network 
depends on the following tasks: 


@ Identifying the time source to use 
@ Determining an efficient configuration 


@ Identifying the communication format 


Identifying an Efficient Time Source 


Internal Time Sources 


Identifying the time source type for your network is based on the 
method of synchronization you choose. See “Determining an Efficient 
Time Synchronization Method” on page 109 for more information. 


Time servers are divided into two types that act as time providers or 
time consumers. These servers function on primarily the same 
principles. These principles are: 


@ All servers provide time to any time provider, time consumer, or 
workstation. 


+ All servers are responsible for their own synchronization, 
meaning that they must decide if they’re synchronized to the 
network’s Universal Coordinated Time (UTC) or not, and report 
its synchronization status. 


@ All servers must adjust their internal clock rates to correct 


discrepancies and maintain time synchronization with other 
network servers. 


Time synchronization provided in NetWare 4 supports three kinds of 
time providers. 


Time synchronization identifies all time consumers as Secondary time 
servers. 


Secondary time servers obtain the time from a Single Reference, 
Primary, or Reference time server. They adjust their internal clocks to 
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External Time Sources 


y 
\4 


synchronize with the network time, and they provide the time to client 
workstations. 


A Secondary time server doesn’t participate in determining the correct 
network time. 


If you use an external time synchronization method, then the time 
provider is identified as an external time source. 


Modem and radio sources are most commonly used to synchronize the 
clocks on workstations and NetWare servers. 


A list of third-party time source services is maintained in NOVLIB forum on 
NetWire. The file is currently named TIMESG. TXT. 


Use your planning documentation and documentation provided by the 
time source to identify setup and maintenance procedures. 


Determining an Efficient Configuration 


Determining an efficient configuration of time synchronization 
depends on the physical layout of your network infrastructure. You 
should reference any planning documents related to the LAN and 
WAN topology of your network. 


There are basically two efficient time server configurations. The two 
configurations are: 


@ Single Reference 
@ Time provider group 


Select one of the time server configurations to model the time 
synchronization strategy of your network. 
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Using a Single Reference Time Server 


NetWare 4 uses a Single Reference time server as its default 
configuration. The first server installed into a NetWare 4 network is 
automatically configured as a Single Reference time server. All other 
NetWare 4 servers installed into the network are configured as 
Secondary time servers. 


The Single Reference time server configuration is adequate for 
networks with the following conditions: 


@ Fewer than thirty NetWare 4 servers 
@ No WAN links 
@ Single time zone 


You should ensure that the Single Reference time server is centrally 
located and is equipped with an accurate internal clock. The Single 
Reference time server should be monitored on a daily basis to ensure 
proper time of day and time synchronization. 


A limitation to a Single Reference time server configuration is the lack 
of fault tolerance if the time server loses its connection for an extended 
period of time. This may cause Secondary servers to fall out of sync 
with the network Universal Configured Time (UTC). 


However, if the Single Reference time server loses its connection, you 
can designate one of the Secondary time servers as a temporary Single 
Reference time server until the original is reconnected. 


The following figure illustrates a Single Reference time server 
providing time to Secondary time servers and to its own client 
workstations. The Secondary time servers, in turn, provide time to their 
own client workstations. 
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Figure 5-1 
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The Single Reference time server works on networks of any size, but the 
time synchronization configuration shown in Figure 5-1 is used 
primarily for small networks that don’t include WAN links. 


If you use a Single Reference time server, avoid using Primary or Reference 
time servers in the same tree because the time references might conflict. 


Using a Time Provider Group 


Using a time provider group requires that at least one server is 
designated as a Reference time server and two servers are designated as 
Primary time servers. The Reference time server polls the Primary time 
servers within the time provider group to vote on the correct time. 


The following figure illustrates a Single Reference time server 
providing time to primary time servers. Primary servers, in turn, 
provide time to Secondary time servers. Each of these servers can 
provide time to their own client workstations. 
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Figure 5-2 

Time Provider 
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Usually, only one Reference time server is installed on a network. If you 
use more than one Reference time server, you must synchronize each 
Reference time server with the same external time source, such as a 
radio clock, atomic clock, or Internet time. 


The following figure illustrates a network using an external time server 
to provide time to two individual Reference time servers. 


Chapter 5: Planning the Time Synchronization Strategy 117 


Figure 5-3 
Two Reference Time Servers Using an 
External Time Source 
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Configured Lists 
Australia Provider Group or SAP Filtering Europe Provider Group 


This configuration requires that you modify the time parameters on the 
NetWare 4 servers in the time provider group. 


The NetWare 4 server that is designated as the Reference time server 
should be placed in a central location. NetWare 4 servers designated as 
Primary time servers should be located either at the same central 
location as the Reference time server or used as locational time servers. 


If you are configuring for a multiple campus network, you should 
distribute Primary time servers strategically across the WAN 
infrastructure. This will reduce WAN traffic by providing a time source 
for Secondary time servers and client workstations at each location. 
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If your WAN infrastructure forces you to have more than seven Primary 
time servers in the time provider group, you should implement 
additional time provider groups as necessary. However, you should 
ensure that each Reference time server is synchronized to the same 
external time source. Reference time servers cannot synchronize time 
with other Reference time servers. 


All other servers in the network should be designated as Secondary 
time servers. 


Identifying the Communication Format 


Time providers and time consumers need to communicate in order to 
send and receive time. Time providers need to communicate with other 
providers in order to vote and negotiate the correct network Universal 
Coordinated Time. 


Time source servers use one of two methods to find each other: SAP, or 
a custom configuration list. 


Using SAP (Service Advertising Protocol) 


By default, Primary, Reference, and Single Reference time servers use 
the Server Advertising Protocol (SAP) to announce their presence on 
the network. Time consumers do not use SAP. 


Primary and Reference time servers use the SAP information to 
determine which other servers to poll in order to determine the network 
time. 


Secondary time servers use the SAP information to choose a time server 
to synchronize with. 


An advantage of the SAP method is that it allows for quick installation 
without regard to the network layout. It also allows automatic 
reconfiguration if operating modes are changed or if new servers are 
added to the network. 


The SAP method, however, generates additional network traffic. 
The SAP method can also be disruptive in large network environments 


where “test” servers come and go, especially if the test server is 
configured as a time source (Single, Reference, or Primary time server). 
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Using a Custom Configuration List 


Custom configuration of your time servers gives you more control over 
time synchronization, but it requires more planning to synchronize 
servers efficiently. 


An advantage of creating a custom configuration list is that you 
maintain complete control of the time synchronization environment. 


Also, custom configuration lists help eliminate nonessential network 
SAP traffic, as well as errors associated with accidental reconfiguration. 


It is also possible to list the specific time source servers that a server 
should contact. 


It is possible to specify that a server should not listen for SAP 
information from other time source servers and that it is not to advertise 
its presence using SAP. 


The custom configuration does require additional time for planning 
and installation. 


Itis also more difficult to install or remove Primary, Reference, or Single 
Reference time servers on the network. You must manually change the 
approved server list maintained on each server. 


To customize your time servers, you can use the SERVMAN utility or 
SET parameters to set the following parameters: 


@ Time Sources 


Lists the specific time source servers that a server should contact. 


% Configured Sources 


Specifies that a server should not listen for SAP information from 
other time source servers. 
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@ Service Advertising 


Disables time source SAP information from being broadcast to the 
network. 


@ Directory Tree Mode 


Indicates the server should ignore time sources advertising via 
SAP if the advertising does not originate on the server’s Directory 
tree. This parameter has no effect if the Configured Sources 
parameter is turned on. 


For detailed information on setting these parameters with SERVMAN 
or the SET utility, see Chapter 4, “Monitoring and Maintaining Time 
Synchronization” in Supervising the Network. 


Using a Combination of Communication Formats 


A VÁ 


Summary 


You can use both the SAP and custom configuration methods on the 
same network. However, the custom configuration list that is stored on 
a server always takes precedence over the SAP information received by 
the server. 


If a server does not have a custom configuration list, SAP information 
is used for time synchronization. 

On a network where servers are rarely added or reconfigured after initial 
installation and where the network uses a Single Reference time server, 
consider using SAP (this is the installation default). 


On a network where servers are added or removed frequently, use a custom 
configuration list. 


Time synchronization is a means to maintain a proper sequence of NDS 
events when the Directory database is partitioned and replicated. 


Time synchronization can be provided by external time sources or 
internal time sources. 
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Evaluation 


Once you have completed planning time synchronization, review the 
following questions to evaluate the efficiency of your plan: 


+ 


Defaults 


If your network meets the following conditions, are you using the 
default settings? 


+ No WAN links exist 
+ Fewer than thirty servers exist 


+ Single time zone exists 


If consistent time with UTC is important, are you connected to 
some type of external time source? 


If you maintain slow WAN links, are you using a configured list? 
If you have more than seven Primary time servers in the time 


provider group, are you implementing additional time provider 
groups synchronized to the same external time source? 


The defaults for time synchronization are as follows: 


Time Server Type Default 





Single Reference The first NetWare 4 server in the network is set up as 


a Single Reference time server. 


Secondary All additional servers in the network after the first 


server are set up as Secondary time servers. 


Where to Go from Here 


To 


Go to 





Create an accessibility plan for Chapter 6, “Creating an Accessibility 
determining how network resources Plan,” on page 125 
are accessed and used 
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To Go to 





Create a migration strategy for Chapter 9, “Developing a Migration 
servers and workstations from a Strategy,” on page 193 

previous version of NetWare or other 

network operating system 


Create an implementation schedule Chapter 10, “Creating an 
Implementation Schedule,” on 
page 223 
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chapter 6 


Introduction 


Creating an Accessibility Plan 


This chapter describes the process used for creating an accessibility plan 
for your network. The following topics are discussed: 


e “Understanding How Network Resources Are Accessed” on 
page 127 


@ “Determining Access Needs” on page 133 
@ “Determining an Efficient Access Control Method” on page 141 


The depth of your Directory tree and number of containers has the 
greatest impact on how network resource are accessed. 


Single server environments with only one or two Directory tree layers 
and limited security concerns might not need to create an accessibility 
plan. 


Access to network resources and file system data in a NetWare® 4 
environment is controlled by the NetWare® Directory Services™ 
(NDS™) technology and NetWare operating system. Network 
resources are all contained in a single-information system represented 
by the Directory tree. 


Each logical and physical resource within the tree is represented as an 
object that can be accessed and managed by its location within the tree 
structure. 


Network file system data is linked to the Directory tree through Volume 


objects, and is represented in the tree structure by its relationship to the 
Volume object. 
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Objectives 


Prerequisites 


Checklist 


The Directory tree structure allows resources to be organized in a 
hierarchical fashion. This hierarchical structure supports intuitive 
access to, and administration of, network resources and services. In 
addition, the tree structure allows for easy security administration on a 
container-by-container basis or single object basis, depending upon 
your particular needs. 


Creating an accessibility plan involves understanding network access 
in NetWare 4, identifying the access needs for your organization, 
determining the most efficient configuration, and developing a system 
for controlling access. 


When creating an accessibility plan for your network, it is important to 
remember that all rights and access control flow down the tree 
structure. This means that when creating the most efficient accessibility 
plan for your network, you should consider the Directory tree structure 
and global access to Directory tree resources. 


You should also create an accessibility plan that provides the most 
effective use of login scripts and global objects for quick access and 
security throughout the network without high management overhead. 


You should identify access and security needs for users, applications, 
and network resources. Afterwards, create accessibility guidelines for 
designing and configuring login scripts and placing access and 
administration objects in the tree. 


This will enable you to use resource maps, location maps, LAN and 
WAN topology maps, organizational charts, and guidelines to 
determine the level of access and security to meet your network’s 
needs. 


l] You should have copies of the following planning documents: 
+ Directory tree structure design draft 
+ Resource maps 
+ Location maps 
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+ LAN and WAN topology maps 
e Organizational charts 


[J You should have completed your Directory tree design 


Understanding How Network Resources Are Accessed 


Because network resources exist in a hierarchical tree structure, 
accessing a particular object requires information about the object’s 
name and location in the tree. Users and network resources use an 
object’s name to locate and interact with other objects. 


Each leaf object has a name to identify it. This name is referred to as the 
leaf object’s common name (CN). For User objects, the common name is 
the User’s login name. Other leaf objects also have common names such 
as a Printer object name, NetWare Server object name, or Volume object 
name. 


Container objects don’t have common names. They are referred to by 
their Organizational Unit (OU) object name, Organization (O) object 
name, or Country (C) object name. 


Identifying Objects by Name 


Complete Name 


y 
v 


An object’s location in the tree is referred to as its context. An object’s 
tree name (Directory name) is identified by the full path from the 
object’s context in the tree to the [Root] of the Directory tree. 


The full path of an object’s location in the tree, which is from its current 
location up to the [Root] object, forms the object’s complete name, or 
distinguished name (DN). 


The term distinguished name is commonly used interchangeably with complete 
name. 


For example, a complete name or fully distinguished name (DN) for the 
User object ESAYERS could be: 


. CN=ESAYERS . OU=SALES . OU=HQ . O=ACME 
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Partial Name 


y 
v 


y 
\4 


The objects in the name are separated by periods, similar to the backslash (/) 
used in DOS paths. A leading period is used. A leading period directs NDS to 
ignore the current context of the object and resolve the name at the [Root] 
object. A trailing period cannot be used. 


An object’s current location in the Directory tree is called the current 
context or name context. The Directory name of an object’s current 
context relative to other Directory objects is referred to as its partial name 
or relative distinguished name (RDN). 


The term relative distinguished name is commonly used interchangeably with 
partial name. 


The partial name is a subset of an object’s complete name. It allows 
resources to search for and locate other Directory objects by their 
relative context (tree location) to each other. This makes referencing 
objects near the requesting object simpler and easier. 


When using an object’s partial name only the portion of that object’s 
complete name that is not common between another objects is used. 


For example, a partial name for the User object ESAYERS relative to 
other objects in OU=SALES would be: 


. CN=ESAYERS . 


The partial name of the User object ESAYERS that has a complete name 
of 


CN=ESAYERS . OU=SALES . OU=HQ . O=ACME 
relative to a Printer object with the complete name of 
CN=PDLJ4_02 .OU=PROD . OU=MFG . O=ACME 


is CN=ESAYERS . OU=SALES . OU=HQ. 


The objects in the name are separated by periods, similar to the backslash (/) 
used in DOS paths. A leading period and trailing period can be used. A leading 
period directs NDS to ignore the current context of the object and resolve the 

name at the [Root] object. A trailing period allows a network resource to select 
a new context when resolving an object’s complete name at the [Root]. 
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A partial name must still be resolved at the [Root] object. This is done 
by adding a trailing period at the end of the partial name. Adding a 
trailing period forces NDS to identify the object’s context and 
automatically resolve the rest of the object’s complete name. 


Typeful and Typeless Naming 


An object’s distinguished name consists of different object types, such 
as common name (CN), Organizational Unit (OU) objects, and 
Organization (O) objects. When the abbreviations of these object types 
are used in an object name, it is referred to as an object’s typeful name. 
For example, 


CN=ESAYERS . OU=SALES . OU=HQ . O=ACME 


In many cases, the abbreviated object types can be omitted when 
referencing a Directory object. This kind of naming is referred to as an 
object’s typeless name. For example, 


ESAYERS . SALES . HO. ACME 


If the object types are not provided in an object’s complete name, NDS 
identifies the attribute type for each object in the name. 


Name Length and Tree Depth 


Maintaining an appropriate depth for your environment enables easier 
access to and management of the network. 


A Directory tree should maintain a depth of four to eight levels. As the 
complexity of your environment increases, either in numbers of objects 
or in the number of locations under single management, then the tree 
depth can easily increase to accommodate those conditions. 


Nevertheless, a limitation of the DOS command line utilities impose a 
maximum context length of 255 characters. If shorter Organizational 
Unit (OU) names are used a deeper tree can be designed. However, the 
greater the depth of the tree, the more complex access to network 
resources may be required. 


The total character count is established by using an object’s complete 


name in its typeful name format. This includes the object type 
abbreviation, equal sign (=), and periods (.). 
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When leaf objects are created, they are checked to ensure that the 
maximum name length of the complete name isn’t exceeded. 


However, it is possible to rename a leaf object and cause the complete 
name to exceed 255 characters. The following example shows an 


acceptable complete name: 


CN=JSMITH.OU=SALES . OU=HQ . O=ACME . ACMECORP 


Identifying Directory Objects by Location 


y 
v 


Network resources search and navigate the Directory tree to locate 
objects in their particular context. For example, a user can navigate from 
one container to another by changing contexts. This doesn’t mean that 
the User object for that user is moved to a different context in the tree, 
but that the user’s view of the Directory tree is changed to a different 
context. 


Nevertheless, once a user changes context, the names of objects in the 
tree for that user’s User object are now relative to the user’s current 
context. This allows users to navigate the tree to find and access 
Directory objects in their particular containers. 


NetWare 4 provides both text-based and graphical utilities for 
navigating the tree. 


A network resource can also use the complete name or partial name of 
an object for searching the Directory tree. 


For the User object ESAYERS to access a Volume object located in the 
HQ container, the following map statement should be used: 


MAP drive_letter:=CN=servername_volumename.OU=HQ.: 


For example, to map the APPS volume of the server SALES1 to drive 
letter G:, type, 


MAP G:=CN=SALES1_APPS.OU=HO. : 


The typeful or typeless can be used for accessing other objects in the tree. 
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Using Access-Related Objects 


Alias Object 


Access-related objects help simplify tree navigation and access to 
commonly-used network resources. 


An Alias object is a pointer to an actual resource object in the tree. An 
Alias object can point to either a container object or a leaf object. 


For example, users in the SALES Organizational Unit object can access 
a Printer object located in the HQ Organizational Unit object through an 
Alias object in their same container. This allows users to reference the 
actual printer by using only the common name of the Alias object. 


Alias objects can also point one Organizational Unit object to another 
Organizational Unit object. This allows the access rights to objects 
within the aliased container to apply to users in the container holding 
the Alias object. 


For example, you might create an Organizational Unit object that holds 
a group of application servers. Users outside of this Organizational Unit 
object might also need access rights to the application servers. If you 
create an Alias object in the users’ container to the container holding the 
application server, the users have the same access rights to the 
application servers that exist for the container that holds the servers. 


Naming Alias Objects 


You might want to give an Alias object a name that indicates that it is a 
pointer to a primary object. For example, the name might include the 
word Alias such as ALIAS MKT_SRV1. 


Inversely, you might not want to distinguish the Alias object from the 


primary object. Users may not need to know the difference, and adding 
Alias to the name might only confuse them. 


Relationship to Primary Objects 
It is important to understand how Alias objects relate to the primary 


objects they point to. Alias objects exist in two different states: 
dereferenced and non-dereferenced (or referenced). 
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Directory Map Object 


y 
v 


When an Alias object is dereferenced, operations performed on the 
Alias object point to the properties of the primary object. This means 
that when changes are made to the Alias object, the changes are actually 
made to the primary object. 


When an Alias object is non-dereferenced, operations performed on the 
Alias object affect only the Alias object itself. Actions such as moving, 
renaming, or deleting an Alias object are automatically non- 
dereferenced. 


If you delete the primary object of an Alias object, the Alias object is 
automatically deleted. 


A Directory Map object allows objects in one container to access file 
system directories or Volume objects located in another container. This 
is useful when a particular application or file can only exist on a single 
volume, but is accessed by objects in many containers. 


For example, users in the SALES Organizational Unit object can access 
a Directory Map object pointing to a database application stored on a 
volume located in the HQ Organizational Unit object. This allows users 
to reference the actual database volume by using only the common 
name of the Volume object. 


Directory Map objects can point to a specific Volume object or file system 
directory on the volume. 


The Directory Map object can manage mappings in container or user 
login scripts. For example, if many different container or user login 
scripts maintain individual drive mappings to a particular application 
directory, they all have to be changed individually when the application 
directory is changed or the application is updated to a new directory. 
Conversely, if container or user login scripts referenced a single 
Directory Map object for the application directory, any changes would 
be reflected only in the Directory Map object itself. 


When you assign the Directory Map object a path to the files or 
applications you are referencing, you must also grant each User object 
Read and File Scan rights to the files or applications in the directory. You 
can do this by granting Read and File Scan rights to the Directory Map 
object, and then make each user security equivalent to the Directory 
Map object. You might also assign file rights to each Organizational 
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Global Group Objects 


Unit object. Users objects are automatically granted security 
equivalency to their particular Organizational Unit objects. 


A Group object contains users from any container in the Directory tree. 
It can be located in any container and be granted any rights. This allows 
you to create a global Group object to regulate global access to the 
Directory tree for a specific set of users. 


For example, you can create a managers group or publications group 
that requires the same access to network resources and include all the 
necessary users in the Group object. This type of Group object allows 
for a single point of access management to a single network resource or 
container of resources. 


Group objects allow you to grant users in Organizational Unit objects 
specialized rights assignments. Therefore, you can manage a much 
smaller subset of users within the Directory tree. 


Determining Access Needs 


When determining the particular network access needs for your 
organization, consider the following issues: 


1. What types of network connections are needed? 

2. What type of NetWare Client™ software is being used? 

3. Are users static or mobile? 

4. What network resources do users access and how are they shared? 


5. Is bindery services needed? 
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Identifying Network Connection Types 


NetWare 4 supports three types of network connections: 


+ 


v 


Attached (not logged in) 


Once the NetWare Client software is loaded, NetWare 4 allows 
users and other network resources to browse the Directory tree 
and locate objects. Limited information is available about each 
object; however, no operations can be performed on the objects. 
No licensed connection is used. 


Authenticated 


When a request is made to a Directory object, an authenticated 
connection needs to be established. This is referred to as a pass- 
through operation. Logging in to the network or changing an object 
property is an example of a pass-through operation that requires 
authentication before it is allowed. No licensed connection is 
used. See “Authentication” on page 142 for more information. 


Licensed 


Once an authenticated connection is established, operations such 
as mapping a network drive or capturing a printer port can be 
performed. When a request for access to a network resource is 
initiated, such as mapping a network drive, a licensed connection 
is used. 


licensed connection by loading utilities from their workstation’s local drives. 


“y Administrators can browse and manage the Directory tree and not use a 
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Identifying NetWare Client Types 


Client Operating System 


NetWare 4 supports for the following NetWare Client types: 


Explanation 





DOS and Windows 


NetWare 4 provides full NDS support for DOS and Windows clients running 
NetWare Client 32™ software. The NetWare Client 32 software supports 
container and user login scripts in DOS and Windows. 


NetWare 4 also provides full NDS support for DOS and Windows clients 
running the NetWare DOS Requester software. The NetWare DOS 
Requester™ supports container and user login scripts within DOS and 
Windows. 





OS/2 


NetWare 4 provides full NDS support for OS/2* clients running the OS/2 
NetWare Requester software. The OS/2 NetWare Requester™ supports only 
a user login script and a default OS/2 script. 





Macintosh 


The NetWare Client for Mac OS software provides access to NDS for 
Macintosh* workstations running System 7.5 or later operating systems and 
includes the familiar interface to NetWare file and print services. 


Macintosh clients do not support container or user login scripts. All drive 
mappings and port captures are maintained through the NetWare Aliases 
extension that enables users to create aliases to files and folders on NetWare 
servers. 





NFS/UNIX 


NetWare 4 provides full bindery-based login for NFS** clients. All resources 
are accessed through bindery services. NFS clients do not support container 
or user login scripts. All drive mappings and port captures are maintained 
through individual user profiles within the operating system. 


Identifying User Types 


All networks support one or both types of network users: 


@ Local 


Local users are static, meaning that they commonly access 
network resources from the same Directory context. Local users 
require that objects they commonly access are placed in close 
proximity to their User object in the tree. In addition, physical 
resources such as printers and applications are connected or 
stored on the server that users attach to. 


@ Mobile 
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Mobile users commonly access network resources from varying 
parts of the network or Directory tree. They may be physically 
located at a different site or logically located in a different part of 
the tree. Easy access to physical network resources and Directory 
tree information should be considered. 


Mobile users require consistent and common network 
configuration. Directory objects should be placed in a common 
fashion throughout the Directory tree. Use of access objects such 
as Alias objects, Directory Map objects, or Group objects should be 
consistent across the Directory tree. 


Application and workgroup servers throughout the network 
should maintain identical file structures if possible. 


Placing an Alias object close to the [Root] for mobile users makes 
login and authentication easier. This eliminates the need for users 
to remember their complete name (distinguished name). 


Efficient placement of partitions in the network helps mobile 
users find Directory information. 


Identifying Global and Shared Resources 


Global and shared resources are common in network environments. 
These resources are used by users across LAN and WAN links. 
Examples of global resources are customer databases, applications, 
e-mail, calendars, telephone books, printers, and application servers. 
Considerations should be made to ensure efficient and intuitive access 
to these resources. 


You might need to create special containers close to the [Root] that 
contain Alias objects or Directory Map objects of global resources. For 
example, you can create a container that has Directory Map objects to a 
common application suite. 


You could also create a container with an Alias object of each network 

user so that global applications such as e-mail would reference a single 
location for Directory information. This container could be partitioned 
and replicated across the network. Because Alias objects are extremely 
small objects with few updates to them, sychronization is very efficient. 
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When a user authenticates to the network, the profiles and scripts for 
that user are executed. If any of those are not kept locally, the login 
process retrieves those profiles and scripts across LAN or WAN links. 


Keeping copies of profiles and scripts close to the user decreases the 
time needed to complete the authentication process. 


Leaf objects such as Volume objects and Printer objects are easiest to 
access when they are in the lowest container level that incorporates all 
the objects that need access to them. 


For example, if a printer is used by two different departments (which 
have separate Organizational Unit containers), place the Printer object 
at a level above the two containers for those departments. 


Identifying Bindery Services Needs 


moray 


Some applications and services which run in the NetWare 4 
environment do not currently take full advantage of the NDS 
technology. To enable users to access these services from the NetWare 4 
environment, Novell created bindery services. 


With bindery services, NDS imitates a flat structure for leaf objects in an 
Organization or Organizational Unit object. When bindery services is 
enabled, all objects in the specified container can be accessed by NDS 
objects and by bindery-based servers and client workstations. 


Bindery services applies only to leaf objects in a specified container object. 


The following figure illustrates bindery services when an 
Organizational Unit object is specified as the bindery context. 
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Figure 6-1 
Bindery Services in 
a Directory Tree 
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A writable replica of the partition that includes the container object to 
be set as the bindery context must be stored on each server you want 
bindery services enabled on. However, by default, only the first three 
servers installed on a partition receive a replica of the partition during 
the installation process and subsequently support bindery services. 


You can add replicas to other servers if needed for bindery services. If a 
read/write or master replica is not present, use the NDS Manager 
option in NetWare Administrator or PARTMGER to add one to the 
server. 


If a bindery context is not set, NDS cannot support bindery services. 


Bindery services is server-centric. If a client workstation does a bindery 
login, the login script comes from the server that the client is logging in 
to. Any changes to the user’s bindery login script are made on a single 
server and are not distributed to other servers. 


You cannot disable bindery services if someone is logged in through 
bindery services, and bindery objects are always available unless 


bindery services is disabled. 


Bindery services allows NetWare 4 servers to support the following 
bindery-based resources: 


e Bindery objects class 


e  Bindery-based NetWare client software 
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@ Users 

% Groups 

+ Queues 

@ Print servers 

+ Profiles 

% Bindery programs 


You should identify what applications and network resources are 
bindery-based, such as jetdirect printers or client workstations. 


Each NetWare 4.1x server supports up to sixteen different bindery 
context settings. If bindery-based applications and resources exist in 
your network, you should consider basing your accessibility guidelines 
on the bindery context for each resource. 


Determining What Objects to Create 


If you or a service require the bindery user GUEST, you must create 
GUEST in the Directory database. 


During installation, a bindery object SUPERVISOR is created but is not 
used with NDS. The NDS utilities do not display this object. This object 
is intended to be used with bindery services and to enable access to the 
server through a bindery login. Once bindery services is enabled, you 
can use this object to log in to the server, providing you log in as a 
bindery object. 


You can create an NDS User object SUPERVISOR and assign ADMIN- 
equivalent rights to it in NDS. However, the bindery object and the NDS 
object are unique and separate objects even though they are identified 
by the same name. 


After installing the NetWare server, you can use a migration utility to 
convert bindery user accounts to NDS User and Group objects. If you 
do, all users except SUPERVISOR and all groups are updated to NDS 
objects. The user SUPERVISOR is migrated, but with supervisory rights 
for that server’s file system and bindery context only. SUPERVISOR 
does not appear as an Directory object. 
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Identifying Possible Limitations 


While bindery services will allow users to access bindery-based 
applications and resources, you need to be aware of its limitations. 


Information Limitations 
Some Novell® Directory Services information is not available to users 
through bindery services. This information includes, but is not limited 
to, the following: 

@ E-mail name 

@ Phone number 

@ = Print job configurations 

@ Aliases 


@ Profiles 


@ NDS login scripts 


Partitioning Limitations 


The bindery context for a server can be set to a container that is part of 
a partition stored on a different server. But, before you can use bindery 
services, you must place a writable replica of the partition that includes 
the bindery context on the bindery services-enabled server. 


If you set the bindery context for a server to a container object that is not 
part of a writable replica on that server, users will not be able to log in 
through bindery services. 


Changing Context Limitations 


Avoid changing a server’s bindery context once you set it. Changing a 
server’s bindery context leaves users in the original context without 
access to bindery services. Changing the server’s bindery context can 
also cut off access to print queues. 
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Network Traffic Concerns 

Needing bindery services on all or nearly all servers to support 
bindery-only aware applications places a extra load on the network due 
to the replication traffic that is exchanged between all instances of a 
partition. 


To reduce network traffic, you could: 


@ Partition farther down the tree so that fewer servers hold the 
replica of any partition. 


@ Move the bindery-only aware applications to certain servers and 
then place replicas only on those servers. 


@ Upgrade old applications, or purchase new Directory-aware 
applications. 


Determining an Efficient Access Control Method 


Access control is an integral part of Novell Directory Services and the 
NetWare file system structure. It determines what actions users can 
perform and what information and resources are available. 

An efficient security structure is easily implemented because most of 
the necessary rights are automatically assigned as Directory objects are 
created. 

Administrators can control users and groups needing access to 
resources, such as data and programs that reside in files and directories. 
They can also protect all the objects at the server level from 
unauthorized access. 


Access control to Directory objects is maintained through the following 
set of features: 


% Authentication 
@ NDS and file system security 
e Login and profile scripting 


% Administrative objects 
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Authentication 


When a NetWare client makes a request for access to a service on the 
network, such as logging in, a server begins a process called 
authentication. Authentication validates a client request by attaching a 
unique code to each request. This unique code is then used to identify 
the following information about each request: 


% The source of the request 

@ What session the request pertains to 

+  Ifany information was counterfeited from another session 
@ Ifthe request data is corrupt or has been tampered with 


For example, authentication occurs when a network user makes a login 
request. NDS returns a unique code to the user request that is attached 
to the user's login information (password, workstation address, and 
time). Based on the current context and the login name, authentication 
identifies the User object to other servers in the tree and verifies that the 
object has rights to use certain resources. 


Authentication enables a NetWare 4 network to support a single login 
for the entire network of servers. 


Authentication allows a user who has logged in to the network to access 
any resource in the network that the user has rights to. If a user lacks 
sufficient rights, access is denied. Authentication checks a user's rights 
to both Directory and file system resources. 


NDS and File System Security 


NetWare 4 supports two divisions of security for the Directory tree and 
file system. 


Novell Directory Services security affects management of the Directory 
tree and its objects. This security is used for managing the Directory 
objects and their properties, such as access between Directory objects 
and their properties, access to login scripts, etc. 


The NetWare file system security affects how Directory objects can 
access files and directories on network volumes. This type of security 
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Trustee Assignments 


provides control of the application programs and data files on network 
servers. 


NetWare 4 file system security is essentially the same as file system 
security used in previous versions of NetWare. Some new attributes 
have been added for features such as data compression and data 
migration. 


NDS security and file system security are based on the same principles 
but function separately. This allows for single or divided administration 
of network resources and network data. 

The common principles for NDS and file system security are: 

% Trustee assignments 

% Inheritance 

@ Inherited Rights Filter (IRF) 


% Security equivalence 


e Effective rights 


A trustee assignment determines the access Directory objects have to 
other Directory objects and their properties, and access to file system 
directories and files. These assignments are made by explicitly 
assigning rights to a Directory object and its properties, and file system 
files and directories. 


Some trustee assignments are automatically made at installation, and 
when certain Directory objects such as User objects and NetWare Server 
objects are created. See “Default Trustee Assignments” on page 162 for 
more information. 
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Inheritance 


Inherited Rights Filter 


Trustee assignments have the following characteristics: 


e Trustee assignments flow from the [Root] to lower branches in the 
Directory tree or from the root to the lower file directories in the 
file system. 


% An explicit assignment at a lower level replaces all trustee 
assignments made at higher levels in the Directory tree or file 
directory. 


@ Selected property rights override rights assigned through the [all 
property rights] attribute. 


@ Every Directory object, file directory, and file maintains a trustee 
list of all User objects, Group objects, or Organizational Role 
objects that have access rights to it. 


e Trustee assignments for the file system are stored in the directory 
entry table (DET), while trustee assignments for Directory objects 
and properties are stored in the ACL (Access Control List). 


Because the Directory tree and file system are hierarchical tree 
structures, rights assigned in the Directory tree or file system flow 
down through the tree. This is referred to as inheritance. Inheritance 
allows rights assigned at upper levels in the tree or file system to flow 
down to subordinate levels. Rights received from upper levels are 
referred to as inherited rights. These inherited rights flow down without 
specific trustee assignments. 


Inherited rights are controlled by blocking specific rights with an 
Inherited Rights Filter (IRF). 


In the Directory tree, objects automatically receive, or inherit, rights 
granted to their parent objects. The IRF is used to block any or all of the 
inherited rights from flowing down to subordinate objects. 


It is important to remember however, that an IRF cannot grant rights; it 
can only block rights assigned to objects at higher levels in the tree. 
Nevertheless, an IRF can be enabled for every file, directory, Directory 
object, and object property. 
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Security Equivalence 


The Supervisor object right and property right can be blocked by an IRF. 
However, the Supervisor rights to files and directories can’t be blocked 
by an IRF. 


Security equivalence allows you to assign rights through association. 
This means that an object can acquire rights by its assigned relationship 
to another object, such as, containers, groups, organizational roles. 


Security equivalence allows an object to be equivalent in rights to 
another object. Every object is security equivalent to the [Root] object 
and the [Public] object trustee by default. This ensures that all objects 
can search and navigate the Directory tree. 


Security equivalent rights flow down through the Directory tree 
independent of any other trustee assignments. Therefore, rights 
assigned to an object do not affect rights received through security 
equivalence. For example, a User object could be made security 
equivalent to a Group object with Supervisor rights to all objects in the 
tree. Any explicit rights assigned to the User object in a particular 
Organizational Unit object will not affect the rights received through 
security equivalence. 


Implied Security Equivalence 


Every object is security equivalent to all container objects that are a part 
of its complete name (distinguished name). This is known as implied 
security equivalence. 


Implied security equivalence is a characteristic of the Directory schema 
and cannot be modified. Because of this, the implied security of an 
object is not viewable by NetWare utilities. 


Security equivalence is not transitive. For example, a User object that is 
security equivalent to User object ADMIN receives security 


equivalences that the User object ADMIN might have with other 
objects. 


Security Equivalence and Inheritance 


Security equivalence differs from inheritance in that inheritance allows 
rights to flow down the tree from parent to child objects until rights are 
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Effective Rights 


NDS Security 


blocked by an IRF. Security equivalence, however, applies only to rights 
granted explicitly to the objects that one maintains security equivalence 
to. 


A simple rule to remember is that inheritance can be blocked by 
enabling an IRF, but security equivalence or trustee assignments cannot 
be blocked. Security equivalence and trustee assignments must be 
explicitly granted and revoked. 


This is important to understand because all objects in an Organizational 
Unit object container are automatically security equivalent to the 
Organizational Unit object. Enabling an IRF for the Organizational Unit 
object does not affect the rights received from the Organizational Unit 
object through security equivalence. 


The actual rights that an objects has is dependant on a combination of 
explicit trustee assignments, inheritance, and the IRF. This combination 
determines an object's effective rights. 


An object’s effective rights are what control its access to another object 
and that object’s properties. These rights define what the object can 
actually do at a particular level in the Directory tree or file system. 


A User object might have explicit trustee assignments at the 
Organizational level, but may have very different rights at lower 
Organizational Unit object levels because of an IRF. This is important to 
understand when calculating the effective rights for a given object. 


Once a user has logged into the network, access to leaf and container 
objects is determined by the NDS security structure. At the foundation 
of NDS security is the Access Control List (ACL. 


The ACL is a property of every Directory object. It defines who can 
access the object (trustees) and what each trustee can do (rights). 


Each object listed in an ACL can have different rights to that object’s 
properties. For example, if ten users are listed in a Printer object’s ACL 
as trustees, each of those ten users can have different rights to that 
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Printer object and to its properties. One object might have the Read 
right, another might have the Delete right, etc. 


To change the trustee’s access to an object, you would change the 
trustee’s entry in the object's ACL. Only trustees with the Write right for 
the ACL property can change the trustee assignments or the Inherited 
Rights Filter. 


The ACL is divided into two types of rights: 


% Object rights 


Defines an object’s trustees and controls what the trustees can do 
with the object. 


@ Property rights 


Limits the trustee’s access to only specific properties of the object. 


In summary, object rights define who can access the object and what 
they can do with the object. Property rights further refine the level of 
access by specifying the object properties that can be accessed. 


Object Rights 


Object rights control what trustees of an object can do with that object. 
Object rights control the object as a single entity in the Directory tree, 
but do not allow the trustee to access information stored in that object’s 
properties (unless the trustee has the Supervisor object right, which also 
includes the Supervisor property right). 
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The following table describes object rights you can assign to a trustee. 





Right Description 





Browse Grants the right to see the object in the Directory tree. Also 
allows a user performing a search to see the object if it 
matches the search value. (This is true only when 
comparing the base object class or partial name; otherwise, 
the Compare right for property objects is required.) 





Create Grants the right to create a new object within a container 
object in the Directory tree. This right applies only to 
container objects because leaf objects cannot contain other 
objects. 





Delete Grants the right to delete an object from the Directory tree. 
However, a container object cannot be deleted unless all 
the objects in the container are deleted first. 


The Write right for all existing object properties is also 
needed to delete objects. 





Rename Grants the right to change the partial name of the object, in 
effect changing the naming property. This changes the 
object’s complete name. 





Supervisor Grants all rights to the object and to all its properties. 
Anyone with Supervisor rights to an object has access to all 
of its properties. The Supervisor right can be blocked with 
the Inherited Rights Filter (IRF). 


Property Rights 


While object rights allow you to see an object, delete an object, create a 
new object, etc., only the Supervisor property right allows you to see the 
information stored in an object’s properties. 


To see the information in an object’s properties, you must have the 
correct property rights. Property rights control access to each property 
in an object. 


Property rights apply only to Directory object properties, not to the 
objects themselves. NDS allows you flexibility in deciding what 


property information others can access. 


The following table describes property rights you can assign to a 
trustee. 
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Right Description 





Add or Delete Allows you to add or remove yourself as a value of the 
Self property, but you cannot change any other values of the 
property. 


This right is only used for properties where your User 
object can be listed as a value, such as group 
membership lists or mailing lists. 


This right is included in the Write right; that is, if the Write 
right is given, Add or Delete Self operations are also 
allowed. 





Compare Allows you to compare any value to an existing value of 
the property. The comparison can return True or False, 
but cannot give the value of the property. 





Read Allows you to read the values of the property. 


This right includes the Compare right; that is, if the Read 
right is given, Compare operations are also allowed. 








Supervisor Gives you all rights to the property. This Supervisor right 
can be blocked by an object's Inherited Rights Filter (IRF). 

Write Allows you to add, change, or remove any values of the 
property. 


This right includes the Add or Delete Self right; that is, if 
the Write right is given, Add or Delete Self operations are 
also allowed. 


The Write right to the Access Control List (ACL) property 
is the same as giving the Supervisor right to the object— 
the right to grant rights. 





Property rights can be assigned in one of two ways, 


% All Properties option 


Assigns the rights you choose to all properties for the object. For 
example, the Read All Properties right setting would allow you to 
view the value of all properties for an object. 
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@ Selected Properties option 


Assigns rights only to the properties that you have specified. 
Granting rights to specific properties overrides any rights granted 
through the All Properties option. This allows you to define 
general rights assignments for a group of objects and specific 
property settings for a select object. 


NetWare File System Security 


y 
v 


NetWare file system security exists at the server level. The server stores 
volumes that contain the directories which contain files. The file system 
security does not transition into the NDS security structure. 


Nevertheless, access to the NetWare file system is controlled by the 
same principles as NDS security. The basic principles include trustee 
assignments, inheritance, and security equivalence. The file system also 
uses Inherited Rights Filters (IRF) which participates in determining the 
effective rights. 


Previous versions of NetWare referred to the file system IRF an as an Inherited 
Rights Masks (IRM). 


There are however a few minor difference between NDS and file system 
security: 


@ NDS has ten access rights divided into two groups: 
+ Objects 


+ Properties 


@ Rights do not flow from NDS into the file system except in the case 
of the Supervisor [S] object rights to the NetWare Server object. 
This grants the trustee Supervisor [S] file system rights to the root 
of all server volumes. 


@ The Supervisor [S] object rights can be blocked by the IRF. The 
Supervisor [S] file system rights cannot be blocked by the IRE. 


File System Access Rights 


Once a user has logged into the network, access to files and directories 
is determined by the NetWare file system security structure. At the 
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foundation of NetWare file system security is the directory entry table 
(DET). 


The DET stores access information about directories and files. It 
contains information about a volume’s file and directory names, and 
properties. 
For example, an entry might contain the following: 

@ Filename 

@ File owner 

@ Date and time of last update 


+ Trustee assignments 


Before you can access files and directories, you must have sufficient file 
system access rights. 


The following table lists the available file system rights for making 
trustee assignments in NetWare 4: 





Right Allows You To 

Access Add and remove trustees and change rights to files and 

Control directories. 

Create Create subdirectories and files. 

Erase Delete directories and files. 

File Scan View file and directory names in the file system structure. 

Modify Rename directories and files, and to change file attributes. 

Read Open and read files, and to open, read, and execute 
applications. 


Supervisor Grant all rights listed in this table. 


Write Open, write to, and modify a file. 
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There are three rights that you should use with caution. 


@ Supervisor [S] 


The Supervisor [S] right grants all privileges to files and 
directories and it cannot be filtered. 


Users with Supervisor [S] rights can make trustee assignments 
and grant all rights to other users. 


@ Access Control [A] 


The Access Control [A] right allows users to make trustee 
assignments but they can only grant the same rights that they 
possess. Access Control [A] also allows users to modify the IRF. 


@ Modify [M] 


The Modify [M] right allows users to change files and directories. 
It also allows users to change file system attributes. 


File System Attributes 


File system attributes assign rights to individual directories or files. 
Some attributes are meaningful only when applied at the file level, but 
some apply to both the directory and file levels. 


Be careful when assigning directory and file attributes. The attribute 
applies to all users. 


For example, if you assign the Delete Inhibit attribute to a file, no one, 
including the owner of the file or the system supervisor, can delete the 
file. But any trustee with the Modify right can change the attribute to 
allow deletion. 
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Table 6-1 lists and explains the rights stored in the directory entry table 
(DET) for files and directories: 


Table 6-1 
Directory and File Attributes 





Attribute Description Applies to 





A Archive Needed identifies files that have been modified since the last Files only 
backup. This attribute is assigned automatically. 


Ci Copy Inhibit prevents Macintosh users from copying a file. This attribute Files only 
overrides Read and File Scan trustee rights. 


Cc Can't Compress indicates the file cannot be compressed because of Files only 
limited space savings. 


Co Compress indicates that a file is compressed. Files only 


Dc Don’t Compress keeps data from being compressed for all files in a Directories and files 
directory or individual files. This attribute overrides settings for 
automatic compression of files not accessed within a specified number 
of days. 


Di Delete Inhibit means that the file or directory cannot be deleted. This Directories and files 
attribute overrides the Erase trustee right. 


Dm Don't Migrate prevents files and directories from being migrated from Directories and files 
the server's hard disk to another storage medium. 


Ds Don't Suballocate prevents data from being suballocated. Files only 


H The Hidden attribute hides files and directories so they can't be listed Directories and files 
using the DIR command. A user with File Scan rights can use FILER or 
the NDIR command to list directories and files with the Hidden attribute. 


Index allows large files to be accessed quickly by indexing files with Files only 
more than 64 File Allocation Table (FAT) entries. This attribute is set 
automatically. 


lc Immediate Compress sets data to be compressed as soon as a file is Directories and files 
closed. If applied to a directory, every file in the directory is compressed 
as each file is closed. 


M Migrate indicates that a file has been migrated from the server's hard Files only 
disk to another storage medium. 


N Normal indicates the Read/Write attribute is assigned and the Directories and files 
Shareable attribute is not. This is the default attribute assignment for all 
new files. 
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Table 6-1 continued 
Directory and File Attributes 





Attribute Description 


Applies to 





P 


Ri 


Ro 


Rw 


Sh 


Sy 





Purge flags a file or directory to be erased from the system as soon as 
it is deleted. Purged files and directories cannot be recovered. 


Rename Inhibit prevents the file or directory name from being modified. 


Read Only prevents a file from being modified. This attribute 
automatically sets Delete Inhibit and Rename Inhibit. 


Read/Write allows you to write to a file. All files are created with this 
attribute. 


Shareable allows more than one user to access the file at the same 
time. This attribute is usually used with Read Only. 


The System attribute hides the file or directory so it can’t be seen by 
using the DIR command. It can be seen if a user with File Scan rights 
uses FILER or the NDIR command. System is normally used with 
operating system files, such as DOS system files. 


Transactional allows a file to be tracked and protected by the 
Transaction Tracking System (TTS). 


The Execute Only attribute prevents the file from being copied, 
modified, or backed up. It does allow renaming. The only way to remove 
this attribute is to delete the file. Use the attribute for program files such 
as .EXE or .COM. Make a copy of a file before you flag it as Execute 
Only, so you can replace the file if it becomes corrupted. 
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Directories and files 


Directories and files 


Files only 


Files only 


Files only 


Directories and files 


Files only 


Files only 


Login and Profile Scripting 


Four Types of Login Scripts 


“yy 
v 


Login scripts define the user’s drive mapping, capture statements, and 
variable settings. They also invoke menus and applications. For ease of 
network administration, users and the resources they use should be 
placed together within Organizational Unit objects. 


When a user logs in, the LOGIN utility executes the appropriate login 
scripts. Four types of login scripts are available, and they can be used 

separately or together to create a custom environment for your users. 

All but the default login script are optional. 


Login scripts are executed in the given order: 


+ 


Container login script 


This sets the general environments for all users in a container. The 
LOGIN utility executes container login scripts first. A user can use 
only one container login script. 


A container login script replaces the system login script from 
NetWare 3™. 


Profile login script 


This sets environments for several users at the same time. The 
LOGIN utility executes a profile login script after the container 
login script. 


A user can be assigned only one profile login script, but can 
specify other profile login scripts on the command line. Several 
users can use the same profile login script. 


User login script 


This sets environments specific to a single user, such as printing 
options or a username for e-mail. The LOGIN utility executes the 
user login script after any container and profile login scripts have 
executed. 


A user can have only one user login script. 
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% Default login script 


This is precoded into the LOGIN.EXE command and is not 
editable. It executes if a user doesn’t have his or her own user 
login script, even if a container or profile login script exists. 


The default login script is executed for all users (including user 
ADMIN) unless you create a user login script. The default login 
script contains only essential commands such as drive mappings 
to the NetWare® utilities. 


If you don’t want to create any user login scripts and you don’t 
want the default login script to execute for any users, you can 
disable the default login script by including the NO_DEFAULT 
command in the container or profile login script. 


To use the login script from an Organization, Organizational Unit, or 
Profile object, users must have the Browse right to the object and the 
Read right to the object’s Login Script property. 


Note WAVay For more information on Browse or Read rights for a file, object, or property, see 
y “Browsing” and “Rights” in Concepts. 


Planning Effective Login and Profile Scripts 


Maintaining many user login scripts can be time consuming. Try to 
include as much customizing information as possible in the container 
and profile login scripts, which are fewer in number and easier to 
maintain. 


For example, if all users need access to the NetWare utilities in the same 
volume, put the search drive mapping to that volume in a single 
container login script rather than in every user login script. 


Create profile login scripts if there are several users with identical login 
script needs. 


Finally, in user login scripts, include only those individual items that 
can't be included in profile or container login scripts. 


Since up to three login scripts can execute whenever a user logs in, 
conflicts can occur. If this happens, the last login script to execute 
(usually the user login script) overrides any conflicting commands in a 
previous login script. 
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Table 6-2 


Login script conventions 


Login scripts are properties of objects. The following table shows which 
objects can contain which login scripts. 








Object Type of Login Script 
Organization Container 
Organizational Unit Container 

Profile Profile 

User User 





The following conventions can help you plan effective login scripts. 





Subject 


Conventions 





Minimum login scripts 


No minimum. All four types of login scripts are optional. Login scripts can 
have only one line or they can have many. There are no required 
commands for login scripts. 





Case 


Either uppercase or lowercase is accepted. Exception: identifier variables 
enclosed in quotation marks and preceded by a percent sign (%) must be 
uppercase. 





Characters per line 


150 characters per line is maximum; 78 characters per line (common 
screen width) is recommended for readability. 





Punctuation and symbols 


Type all symbols (+, %, “, _ ) and punctuation exactly as shown in 
examples and syntax. 





Commands per line 


Use only one command per line. Start each command on a new line; press 
<Enter> to end each command and start a new command. 


Lines that wrap automatically are considered one command. 


WRITE command output displays better if WRITE is repeated at the 
beginning of each wrapped line. 
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Table 6-2 


Login script conventions 


Subject 


Conventions 





Sequence of commands 


Generally, enter commands in the order you want them to execute, with the 
following restrictions: 


+ ATTACH commands must precede related MAP commands to avoid 
prompting the user for a username/password during login. 


+ If you use “#’ to execute an external program, it must follow any 
necessary MAP commands. 


+ If sequence is not important, group similar commands, such as MAP 
and WRITE commands, together to make the login script easier to read. 





Blank lines 


Blank lines don’t affect login script execution. Use them to visually 
separate groups of commands. 





Remarks (REMARK, REM, Lines beginning with REMARK, REM, an asterisk, or a semicolon are 
asterisks, and semicolons) comments, which don’t display when the login script executes. Use 


remarks to record the purpose of each command or group of commands. 





Identifier variables 


Type identifier variables exactly as shown. For the value of an identifier 
variable to be displayed on the workstation’s screen as part of a WRITE 
command, you must enclose the identifier in quotation marks and precede 
it by a percent sign (%). 


Global Login Scripts 


Netware 4 does not use a global system login script. Each 
Organizational Unit object you create has its own login script (container 
login script). The order of execution of login scripts is as follows: 


1. Container login script, if present 
2. Profile login script, if used 


3. User login script or the default login script if no other script is 
available 


If you want to create a more global login script and include users from 
multiple Organizational Unit objects, you could use the Profile object to 
set up a specific environment for a group of users. A Profile object 
provides an additional set of drive mappings to what is specified in a 
container login script. 
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Creating Location Login Scripts 


A Profile object can also be used to determine resource allocation based 
on location. For example, suppose each floor of your company has three 
printers and three print queues, and you want to be able to assign a 
particular group of users to a specific print queue. You can use a Profile 
object to capture to a particular print queue. The users whose profile 
attribute has been specified will automatically capture to that print 
queue. 


Creating Special-Function Scripts 


You can create a Profile object for a special function script, such as one 
to assign access for applications. For example, you can create a profile 
script that will be used by backup administrators only. This script may 
give these users a specific drive assignment to backup software and 
utilities. 


Administrative Objects 


User Object ADMIN 


y 
v 


The following objects help administer access to the network: 
@ User object ADMIN 


@ Organizational Role object 


The first time you log in to a new Directory tree, you log in as the User 
object ADMIN—the only User object created during the NetWare 4 
installation process. ADMIN is created when you first set up a 
Directory tree but not when you later add other servers to an existing 
tree. 


ADMIN is assigned all rights (including the Supervisor right) to every 
object and property in the Directory tree. This gives ADMIN complete 
control of the Directory tree. 


When you first log in to a new Directory tree, you may want to create a User 
object and assign that object Supervisor rights to ensure that you have more 
than one object with sufficient rights to completely control the tree. Such an 
object can be critically important if the ADMIN object is deleted accidentally. 
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When it is created, ADMIN is assigned the Supervisor object right to the 
NetWare Server object. This gives ADMIN the Supervisor right to the 
root directory of all NetWare volumes attached to the server, so ADMIN 
can manage all directories and files on every volume in the Directory 
tree. 


ADMIN does not have any special significance like that of 
SUPERVISOR in previous versions of NetWare. ADMIN is granted 
rights to create and manage all objects simply because it is the first 
object created. 


You can rename or delete ADMIN at any time; however, you should 
assign another User object the Supervisor object right to the [Root] 
object before you delete ADMIN. 


ADMIN, then delete ADMIN, the new User object loses the security 


“y If you create a User object and assign it security equivalence to User object 
v 
equivalence. 


User object. Neglecting to do so can be disastrous because you eliminate 
supervising control of the Directory tree. Restoring access to the tree can only 
be accomplished with the assistance of Novell Technical Support. 


"annoy Never delete ADMIN without having assigned the Supervisor right to another 


This warning also applies to other sections of the Directory tree where you have 
a User object ADMIN defined. At each level of the tree where you have ADMIN 
defined, be sure you also have a User object with explicit Supervisor rights. 


It is also important to remember that rights can be granted at a container, and 
they can also be taken away. If all rights are filtered at a container and there is 
not a user in that container with all rights, then that container is without full 
administrative rights. This can cause problems. 


Organizational Role Object 


The Organizational Role is similar to a Group object. The basic 
difference is that a Group object is generally used in a login script and 
is activity oriented (such as for accessing an application on your server). 
Organizational Role objects are not used in login scripts and are more 
suited to creating administrators containing a small number of 
occupants. The Organizational Role object has an attribute known as 
“role occupant.” 


An occupant can be moved in and out of the Organizational Role 


quickly to facilitate short term assignments. If the regular administrator 
is absent for any length or time, another user can be moved into the 
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Summary 


Evaluation 


administrative Organizational Role temporarily to manage the 
network. 


You create the Organizational Role object and assign specific rights 
depending on the characteristics needed for the role. You then assign 
users to the Organizational Role as occupants through NetWare 
Administrator or NETADMIN. 


Efficient planning decrease the amount of time necessary to manage 
installation of NetWare 4 by placing users, services and resources in 
proximity to each other within the tree. 

This allows you to grant most rights to a container and have those rights 
flow through the tree to the users that will need them. For example, 
applying rights once to a container could effectively manage all the 


resources within a given container, which minimizes the time spent to 
administer the Directory tree and reduces network traffic. 


Once you have completed your accessibility plan, review the following 
questions to evaluate the efficiency of your plan: 


@ What applications are used in the organization? 
@ What applications are used by everyone on the network? 


% Are any resources such as applications, directories, or printers 
shared across different locations or workgroups? 


@ Will all users in a certain container have the same access to a 
resource? 


% How will you modify user access to resources? 
@ What client operating systems exist on the network? 


@ How many applications or network resources require bindery 
services? 
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Defaults 


Default Trustee Assignments 


Trustee 


User object that created 


the NetWare Server object 


Directory NDS rights 


Supervisor [S] right to 
NetWare Server object 


A new user has enough rights to read all their own properties, but can 
view only group membership, network address, and default server for 
other users. The login script is the only explicit read property defined 

for container objects. 


NetWare administrators need to assign an “explicit trustee” of a 

property before the property can be used or shared. For example, a print 
job configuration does not work if defined at the container level and not 
assigned for a specific user. 


The default trustee assignments set at installation are as follows: 


File System rights 








User object ADMIN 


Supervisor [S] right to 
[Root] object and to the 
NetWare Server object 
that it creates 





[Root] object 


Read property [R] right 
to each Volume 
object’s Host Server 
Name property and 
Host Volume Name 
property 





[Public] object 


Read property [R] right 
to Server’s Network 
Address property 
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Trustee Directory NDS rights File System rights 


Server volumes Read property right to Read [R] and File Scan 
Login Script property [F] to SYS:PUBLIC 


of the container 
Read [R] and File Scan 


[F] to SYS:DOC 
(optional) 


Read [R], File Scan 


[F], Create [C] Edit [E] 
to SYS: 


User Object Rights at Creation 
User objects inherit the following default rights when they are created: 


Table 6-3 
User Object Rights 




















Object Name Explicit Trustee Object Rights from Property Rights for User 
PUBLIC 
Organization or Organizational Container name Browse Login script 
Unit Read 
Directory Map None Browse None 
Group [Root] Browse Members 
Read 
Profile script None Browse None 
User script Username Browse All properties 
Read 
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Default Object and Object Property Rights 

The default NDS object and NDS object property rights for newly 
created objects are listed in the following table. These rights are shown 
as an ACL entry with the following format: 

@ = Which object or object property has the rights 

@ Rights to which object or object property 

@ What are the default rights 
The term [Entry Rights] means the rights to the object itself, while [All 
Attribute Rights] means rights to all attributes of the object. Values not 
in brackets (such as Network Address) are actual property names. 

For example, the [Creator] of a Group object has Supervisor rights to the 
object’s [Entry Rights], meaning that the creator has Supervisor object 
rights to the object. 


The [Root] object has Read rights to the Member object property, 
meaning that every user can read the membership of the group object. 























Object Name Default Object Rights Default Object Property Rights 
AFP Server [Creator], [Entry Rights], [Public], Messaging Server, 
[S] [R] 
[Self], [Entry Rights], [S] [Public], Network Address, 
[R] 
Alias [Creator], [Entry Rights], 
[S] 
Audit File [Creator], [Entry Rights], 
[S] 
Bindery Object [Creator], [Entry Rights], 
[S] 
Bindery Queue [Creator], [Entry Rights], [Root], [All Attribute Rights], 
[S] [R] 
Computer [Creator], [Entry Rights], 
[S] 
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Object Name 


Default Object Rights 





Default Object Property Rights 





Country 


[Creator], [Entry Rights], 
[S] 





Directory Map 


[Creator], [Entry Rights], 
[S] 





External Entity 


[Creator], [Entry Rights], 
[S] 


[Root], Member, [R] 





Group 


[Creator], [Entry Rights], 
[S] 


[Root], Member, [R] 





NetWare Server 


[Creator], [Entry Rights], 
[S] 


[Self], [Entry Rights], [R] 


[Public], Messaging Server, 
[R] 


[Public], Network Address, 
[R] 





Organization 


[Creator], [Entry Rights], 
[S] 





Organizational Role 


[Creator], [Entry Rights], 
[S] 





Organizational Unit 


[Creator], [Entry Rights], 
[S] 


[Self], Login Script, [R] 





Print Server 


[Creator], [Entry Rights], 
[S] 


[Self], [Entry Rights], [R] 


[Public], Network Address, 
[R] 











Printer [Creator], [Entry Rights], 
[S] 
Profile [Creator], [Entry Rights], 
[S] 
Queue [Creator], [Entry Rights], [Root], [All Attribute Rights], 


[S] 


[R] 
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Object Name Default Object Rights Default Object Property Rights 





User [Creator], [Entry Rights], [Public], Message Server, [R] 
S 
[Sl [Root], Group Membership, 
[Root], [Entry Rights], [B] [R] 
[Root], Network Address, [R] 


[Self], [All Attribute Rights], 
[R] 


[Self], Login Script, [R,W] 


[Self], Print Job 
Configuration, [R,W] 





Volume [Creator], [Entry Rights], [Root], Host Resource 
[S] Name, [R, W] 


[Root], Host Server, [R] 


For objects that are installed with NetWare 4, the [Creator] is the 
ADMIN User object. 


The ability for a user to create the object in the first place derives from the user 
having a Create right to the container in which the object is created. 


When you create an object, the server optimizes the ACL to remove 
unnecessary entries. Typically, this means that the ACL entry 
“[Creator], [Entry Rights], [S]” is removed, since in most cases the 
creator of an object has the Supervisor rights to the container where the 
object is found, and hence has the Supervisor rights to the newly 
created object by inheritance. 


If, however, the creator only had the Create rights to the container, then 
the ACL for the newly created object retains the “[Creator], [Entry 
Rights], [S]” entry, since the creator would not otherwise have any 
rights on the newly created object. 


Thus, if you create an object and then set its Inherited Rights Filter, you 
may no longer have access to the object, even though the “[Creator], 
[Entry Rights], [S]” ACL entry would appear to give you such rights. 


Effective rights can be derived from security equivalence and inheritance, as 
well as being directly assigned to a user. When assigning rights to any NDS 
object property, you should understand how effective rights are computed. 


166 Place Book Title Here 


Wamingyy =>" Do not make nonadministrative users security equivalent to any NDS server 
Y object such as NetWare Server, AFP Server, or Print Server. 


default. Any user, whether they are logged in or not, is security equivalent to 
[Public]. If you want to allow all users access to a property, it is better to assign 
those rights to [Root] or to the container the users are in. 


veo You should never assign any rights to [Public] beyond what is assigned at 


Where to Go from Here 








To Go to 
Create a migration strategy for Chapter 9, “Developing a Migration 
servers and workstation from a Strategy,” on page 193 


previous version of NetWare or other 
network operating system 


Create an implementation schedule Chapter 10, “Creating an 
Implementation Schedule,” on 
page 223 
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chapter 7 


Introduction 


Designing a Data Protection Plan 


All network environments benefit from creating an effective data 
protection plan. You should ensure that some measure is taken to 
protect your network data. 


This chapter describes the process used for designing a data protection 
plan for your network. The following topics are discussed: 


o “Establishing a Redundant Hardware System” on page 170 
@ “Ensuring Adequate Partitioning and Replication” on page 171 
@ “Developing a Backup and Restore Strategy” on page 172 


e “Creating a Disaster Prevention and Recovery Plan” on page 177 


NetWare® 4™ networks maintain data in the file system and in the 
Directory database. The file system stores files and applications that are 
used by network users and resources. The Directory database stores 
information that is used to maintain and manage operation of the 
network, such as access to network resources, printing, and security. 
To adequately protect both file system and Directory database 
information, you should ensure that the following provisions are 
included in your plan: 

@ Redundant hardware 

% Partitioning and replication 


@ Backup and restore system 


@ Disaster prevention and recovery plan 
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When creating a data protection plan for your network, it is important 
to remember that the file system and Directory database information 
are maintained as separate systems. This means that when you create 
the most efficient data protection plan for your network, you should 
analyze what methods ensure the most efficient data protection for each 
individual system. 


Objectives 


You should identify backup and restore needs, data integrity needs, and 
fault tolerance needs. 


This will enable you to update your existing backup and restore 
methods and develop a disaster recovery plan for your network to 
determine the level of data protection you need. 


Prerequisites 


Checklist l] You should have copies of the following planning documents: 
y Backup plans 

Disaster recovery plans 

Location maps 

Resource maps 

Directory tree structure 


6... .. .. . + 


Partitioning guidelines 


l] You should have completed your Directory tree design. See 
Chapter 3, “Designing the Directory Tree Structure,” on 
page 39for more information. 


Establishing a Redundant Hardware System 


Although the reliability of computer systems has improved 
considerably over the last several years, hardware failures still can— 
and will —occur. Numerous technologies are available to provide more 
reliable data storage and better protection against hardware faults. 
Many of these technologies involve hardware redundancy of some 
kind. 
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For example, RAID (redundant array of inexpensive disks) hard disk 
systems maintain data even if one of the disks fails. 


NetWare’s disk mirroring and duplexing feature also protects against 
hardware failures in the disk channel. NetWare SFT III takes fault 
tolerance a step further and allows two servers to be mirrored. If a 
failure occurs on one server, the other one continues to service the 
network without interruption. See Chapter 5, “Install NetWare 4.11 SFT 
IIL,” in Installation for more information. 


Another possibility is to maintain a standby server to which you can 
attach your regular server’s external disk subsystem in case the server 
experiences an internal hardware failure. Several third-party vendors 
offer standby-server products that allow for a hot copy of data from one 
system to another. 


Ensuring Adequate Partitioning and Replication 


In a network with more than one server, NDS provides online backup 
of the Directory database through the placement of partition replicas on 
multiple servers. For example, in a two-server network with one 
partition, the NDS database is protected by placing a replica of the 
partition on each server. If one replica is lost because of a hard disk 
failure or because volume SYS: is damaged, NDS remains intact due to 
the replica on the other server. 


In the event of an unforeseen loss of a server or volume, you can restore 
lost Directory information through an active replica. Replication also 
allows a replica that becomes damaged to be either rebuilt or recreated 
from another replica. 


See Chapter 4, “Determining a Partition and Replication Strategy,” on 
page 85 for more information. 


Replication is the first line of protection for the Directory database. 
However, it does not provide sufficient protection in a single-server 
environment, or if replicas do not exist, or if all replicas become 
damaged. It also does not provide any protection for the file system. For 
these reasons, a regular backup of your network information must be 
maintained. 


Chapter 7: Designing a Data Protection Plan 171 


Developing a Backup and Restore Strategy 


While replication provides the fault tolerance needed to maintain a 
working Directory tree, you must also include a full, offline backup of 
the file system and Directory database in your data protection plan. 


It is important to remember that the Directory database is a distributed 
system that is dependent upon files stored on multiple servers. You 
cannot back up and restore the Directory database files directly ona 
per-server basis as done in previous NetWare versions. 


NetWare 4 provides a backup and restore solution for your network 
through Storage Management Services™ (SMS™). Using Novell’s 
SBACKUP utility or third-party applications, you should design a data 
protection plan to ensure that your file system and network data are 
protected from loss or disaster. 


Third-Party Solutions 


Third-party backup package vendors can also use SMS to enable their 
backup software to work on a NetWare network. Contact your Novell® 
authorized reseller for a list of backup solutions that have been certified 
by Novell Labs. 


You can also receive Novell Labs Bulletins with a list of the most current 
certification list by accessing the Novell Labs faxback system. 


To access the Novell Labs FaxBack Service, complete the following 
steps: 


1. Within the continental United States, dial 1-800-414-LABS 
(1-800-414-5227). 


2. Outside the continental United States, dial 1-801-861-5544. 


Follow the directions provided on the phone. You are prompted to enter 
a document number and then a fax number to send the document to. 
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Compatibility 


y 
v 


Novell has SMS TSA software available for NetWare 3.11 and 3.12 
servers, NetWare 4.01/4.02, and NetWare 4.1x servers, Novell Directory 
Services, NetWare SOL™, and DOS and Windows*, OS/2*, Macintosh*, 
and UnixWare* clients. 


Itis highly recommended that the backup product used to back up your 
NetWare 4 servers utilize Novell's TSANDS.NLM to back up NDS, and 
TSA410.NLM to back up the file system. 


Backup applications designed for the NetWare 37M environment may 
not handle NetWare 4 data correctly. (For information about the 
capabilities of specific backup applications, contact the application 
vendor.) For backing up and restoring NetWare 4, you should use 
applications which fully support the SMS architecture. 


Because implementation details vary from vendor to vendor, it is important to 
review the documentation and readme files included with the SMS backup 
application of your choice. If the solution you choose has been tested and 
approved by Novell Labs, you can also obtain information on this product from 
Novell Labs Bulletins. 


Determining Backup Administration Strategy 


Since NDS is a distributed database, there can be multiple 
administrators who assist in maintaining the tree. In dividing up this 
responsibility, consider your backup needs and grant the necessary 
rights to those users who will perform the backup and restore 
operations. 


In many cases, it works well to have a central backup administrator 
who has ultimate responsibility and a global view of the entire 
Directory tree for backup and restore purposes. Having a central 
backup administrator will help eliminate problems with incomplete 
backups resulting from the backup user not having sufficient rights to 
certain portions of the Directory tree. 
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Considering Network-Related Issues 


Novell has identified four representative network environments, each 
of which has different ramifications on backup and restore strategies. 


Single Server/Single Partition 


In a single-server network, you can't have more than one replica. 
Further replication is not possible because there is no other server on 
which to store a replica. In this environment, you absolutely must 
maintain a full offline backup of the Directory database information. 
This is the only way you'll be able to restore lost Directory database 
data. 


Multiple Servers/Single Partition 


In a network with more than one server holding a single Directory 
partition, you should have at least two replicas of the partition, 
preferably three. 


Maintaining an offline backup of the Directory database is also 
essential. If the servers are all located at the same site, be prepared in the 
event of a disaster that could destroy all the servers. Store a complete 
set of your backup media at another location, if possible. 


Multiple Servers/Multiple Partitions 


y 
v 


A network with multiple servers holding multiple partitions, both 
online replication and offline Directory database backup are essential. 
Wherever possible, have at least three replicas of each partition located 
on servers throughout the network. 


Avoid having all replicas of a partition located on servers at the same 
site. It is a good idea to keep a complete set of your backup media off- 
site as well. Because SMS backup ignores partition boundaries, 
restoring the Directory tree, especially a partial restoration, is more 
involved. You'll need to keep a written record of how your partitions 
and replicas are set up. 


If you lose one partition and all its replicas, you can restore the objects that 
existed in that partition. However, the procedure for rebuilding the links to the 
lost portion of the Directory tree requires significant technical expertise and 
should be performed with the assistance of a qualified technician. See “Multiple 
Servers/WAN Connections” on page 175 for more information. 
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Multiple Servers/WAN Connections 


Remote sites connected via WAN links require additional 
considerations for backing up the Directory tree. In particular, you 
should consider backup and restore needs when deciding how to 
administer the tree, either centralized with a single administrative user 
account that has full rights to the entire tree, or distributed with 
separate administrative accounts at each site. 


To minimize data traffic across WAN links and to speed up backup and 
restore operations, consider performing backups locally at the remote 
sites. You might also design your Directory tree so that you have 
replicas of every partition stored at the same site as the backup host 
server. Then you can back up and restore the Directory database 
without having data go across WAN links. 


If you back up and restore the Directory database and file system data 
for remote sites from a central location, you should ensure that the 
WAN connections, such as routers, bridges, and telecommunications 
links are functional before you begin. 


If your host and target servers or workstations are not able to 
communicate across the network, a complete backup or restore is not 
possible. 


Data Protection Guidelines 


Efficient planning decreases the amount of time necessary to manage 
backup and restoration of the Directory database. It also ensures that a 
sufficient data protection plan is established before implementing 
NetWare 4 on your network. 


The following guidelines should be followed when designing a data 
protection plan: 


1. Use replication as the first level of protection for NDS. 


In multiple server networks, have at least three replicas of every 
NDS partition stored on various servers throughout the network. 
Use your offline SMS backup to restore NDS data only if it cannot 
be restored from a replica. 
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Choose a backup product that is certified for NetWare 4. 


To handle NDS and other NetWare 4-specific features, the third- 
party backup program you use should be certified by Novell Labs. 
It should also support SMS and its TSA software. (For product 
certification information, call Novell Labs FaxBack at 800-414- 
5227 or 801-861-2776.) 


Make sure you have the latest versions of backup-related 
software. 


Periodically check with Novell and with your third-party vendor 
to ensure you have the latest version of the backup program, 

device drivers, TSA software, and so on. Novell provides updates 
on NetWire®, the World Wide Web, and the NSEPro™ CD-ROM. 


Stay current with the newest operating system patches and NLM 
versions. 


Periodically check Novell’s electronic distribution sources 
(NetWire, World Wide Web, and NSEPro CD-ROM) for updates to 
the NetWare 4 operating system, Novell Directory Services 
(DS.NLM), and NDS utilities such as NDS Manager, DSTRACE, 
and DSREPAIR. 


Keep a record of where NDS partitions and replicas are located. 


Restoring NDS is much smoother if you have a record of your 
partitions and replicas. Be sure to note the full name of the 
container each server is added into and which replicas are stored 
on the server. See “Replica Placement Worksheet” on page 286 for 
more information. 


You can also use NDS Manager or DSREPAIR to record this 
information to a log file. 


Ensure that NDS is fully functional and WAN links are up before 
backing up or restoring. 


WAN links should be up and servers should be able to 
communicate with each other. All NDS partitions should be 
synchronizing without errors. 


Back up NDS regularly. 


The frequency of backing up NDS depends on how often you 
make changes to your tree. For trees that change often, back up 


NDS every time you do a full network backup. Always back up 
NDS before making major modifications to the tree. 


8. Verify the completeness of each backup and restore session. After 
each backup and restore session, check the appropriate error and 
log files to make sure the process completed successfully and 
didn’t skip crucial portions of your data. 


9. Don’t change NDS object names and contexts when restoring. 


Don’t use a restore situation to “redesign” your NDS tree. The 
restore process will go much more smoothly if you keep the NDS 
tree the same and restore servers to the same container objects as 
they were in before. 


10. Always restore NDS information before restoring file system 
information. 


File system trustee assignments will be affected by restoring NDS 
objects. To avoid problems, always restore NDS information 
before the file system. 


11. Remember to “re-update” your software when reinstalling 
servers. 


After reinstalling NetWare 4 or NDS from the original media, 
remember to reapply OS patches and recopy updated drivers, 
NLM software, and utilities before proceeding with a restore. 


Creating a Disaster Prevention and Recovery Plan 


A disaster prevention and recovery plan provides both preventative 
and responsive action to system or Directory failure caused by 
hardware failure in a NetWare server or by corruption in a Directory 
partition. 


Writing and testing efficient disaster recovery plans and procedures is 
essential for recovery from catastrophic failures such as fire, floods, and 
earthquakes. For information on disaster recovery plans, see the 
manufacturer’s documentation for your backup system or contact your 
Novell® support provider. 
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Summary 


Efficient planning decreases the amount of time necessary to manage 
backup and restoration of the Directory database. It also ensures that a 
sufficient data protection plan is established before implementing 
NetWare 4 on your network. 


In multiple server networks, have at least three replicas of every NDS 
partition stored on various servers throughout the network. Use your 
offline SMS backup to restore NDS data only if it cannot be restored 

from a replica. Use replication as the first level of protection for NDS. 


You should always keep your backup software current and ensure that 
it is compatible with all of the NetWare operating systems running in 
your network. 


Where to Go from Here 





To Go to 
Create a migration strategy for Chapter 9, “Developing a Migration 
servers and workstation from a Strategy,” on page 193 


previous version of NetWare or other 
network operating system 





Create an implementation schedule Chapter 10, “Creating an 
Implementation Schedule,” on 
page 223 
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chapter 8 


Introduction 


Designing an Application 
Management Strategy 


All network environments benefit from creating an effective application 
management strategy. 


This chapter describes the process designing an application 
management strategy for your network. The following topics are 


discussed: 

@ “Ensuring NetWare Compatibility” on page 181 

e “Creating Efficient and Intuitive Application Directories” on 
page 182 

e “Identifying Efficient Application Management Tools” on 
page 185 

e “Identifying Efficient Licensing and Metering Tools” on page 188 

+ “Application Management Guidelines” on page 190 


Network applications are the productivity tools for your organization. 
How you manage these tools depends on the type of applications you 
are using. 


Network applications can be divided into three types: 


+ 


Network-aware 


Applications that run efficiently on the network, but do not use 
any special network features such as storage and messaging 
services. 
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@ Network-enabled 


Applications that run efficiently on the network, but use 
proprietary solutions for services such as authentication, print 
management, and messaging. 


@ Network-integrated 


Applications that are designed to take advantage of special 
network features such as the Directory database and storage 
services. 


Most network applications in use today are network-aware, but not 
truly network-integrated. This poses a challenge for network 
administrators when managing large databases across multiple 
applications and maintaining proprietary methods for implementing 
network services such as messaging and printing. 


Following some simple guidelines and using efficient management 


tools can greatly reduce the amount of time and effort needed to 
manage applications. 


Objectives 
The objectives in designing an application management strategy are 


% Ensuring that all your applications are compatible with the 
version of NetWare® you are using. 


% Creating an efficient and intuitive directory structure for the 
application software and support components. 


@ Identifying tools that provide ease of distribution, installation, 
access, and operational control. 


@ Determining and implementing an efficient licensing and 
metering strategy 
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Prerequisites 


Checklist l] You should have copies of the following planning documents: 
y + Backup plans 

Location maps 

Resource maps 

Directory tree structure 


+ ©% . o 


Partitioning guidelines 


l] You should have completed your Directory tree design. See 
Chapter 3, “Designing the Directory Tree Structure,” on 
page 39for more information. 


Ensuring NetWare Compatibility 


You should determine whether your applications are NetWare 
compatible before you purchase them. Approximately 5,000 software 
packages are compatible and registered with Novell”. This 
compatibility information is important because NetWare makes 
demands on application software that can cause corrupt data orimpede 
user's productivity. 


Information about NetWare compatibility and registration are available 


on NetWire® or from your local Novell sales office. You can also contact 
the software vendor directly. 


Novell's Yes Program 


To be certain of compatibility with NetWare, look for one of the 
following symbols: 


Ae ME AS MEA 
MS DC Bisse Biss 


GroupWise ManageWise NetWare. Telephony 





The Yes Program, Novell's trademarking and certification program, 
helps Novell customers identify and purchase Novell-compatible 
third-party hardware and software products. The Yes Program 
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provides developers with the opportunity to test and certify their 
products against Novell’s strict quality standards to ensure that their 
products are compatible with Novell products. Once products have 
passed the Yes Program’s business and certification requirements, they 
are eligible to use a Yes logo. 


The Yes Program identifies products that are compatible with NetWare 


network operating systems and other Novell products such as 
ManageWise™, GroupWise™, and NetWare Telephony ServicesTM, 


Ensuring Applications Are Designed for Multiple-User Access 


All applications should support multiple users simultaneously. This 
means that it provides file-sharing and multiple-user access. 


If your applications are designed to run on standalone computers, don’t 
assume that they will automatically operate on the network. NetWare 


4™ allows almost all single-user applications to run across the network, 
but, it does not provide data or resource sharing for these applications. 


Using the Application Compatibility Template 
Before installing and configuring applications on NetWare 4.11 in your 
network environment, test the applications in a lab environment. For 
information about setting up a lab, see “Setting Up a Lab” on page 216. 
While testing the applications in the lab, use the Application 


Compatibility template to record your test results. For a copy of the 
template, see “Application Compatibility” on page 277. 


Creating Efficient and Intuitive Application Directories 


Creating efficient and intuitive application directories requires you to 
% Create the application directory structure 
@ Provide adequate load balancing 


@ Protect the application directories 


182 Place Book Title Here 


Creating the Application Directory Structure 


Before installing and configuring applications on a NetWare server, you 
should create an efficient and intuitive directory structure to install the 
applications in. This also provides for easy and efficient access control 
implementation. 


Your application directory structure should be designed to meet the 
specific needs of your organization and applications requirements. 
Most organizations have a variety of applications that are supported on 
many operating systems. The structure you choose should allow for 
access by all types of client workstations. 


The most important consideration to make when creating application 
directories is to separate the applications program files from the data 
files that are created within the applications. 


By separating the program files from the data files, you can easily 
control access and better support data protection plans. You might also 
consider separating program and data files by placing each on different 
volumes or servers. This will help balance the load on servers by 
reducing the amount of traffic on the server. 


Providing Adequate Load Balancing 


To ensure that adequate load balancing is provided, consider the 
following: 


@ Sufficient hardware exists to support the number of necessary 
connections, RAM and disk space requirements, and processor 


speed. 


% Applications servers are physically near the users that use its 
applications. 


+ There are enough servers to efficiently support the number of 
users who need access to the applications. 


% Access control is established to ensure that access to application 
server is spread equally across servers. 
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@ Application licenses that might be server-based require additional 
licenses for more than one server. Ensure that you have enough 
licenses to support your organization’s needs. 

By making considerations for load balancing, you can greatly enhance 
your network’s flexibility and potential for optimization. You can also 


configure management of the application servers to support centralized 
or distributed methods to suit your management style. 


Protecting Application Directories 


Your application programs must be protected from a variety of 
conditions or disasters. 


You should ensure that you are protected from the following conditions 
through proper access control: 


% Accidental deletion 

% Intentional deletion 

@ User access 

% Concurrent use of application licenses 


For information about setting up and configuring proper access control, 
see Chapter 6, “Creating an Accessibility Plan,” on page 125. 


You should ensure that you are protected from the following conditions 
through proper disaster recovery methods and backups: 


@ Server failure 

% Catastrophe 

% Application or data theft 

@ Software updates 
For information about setting up and configuring a sufficient data 


protection plan, see Chapter 7, “Designing a Data Protection Plan,” on 
page 169. 
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Identifying Efficient Application Management Tools 


Application management consists of managing ease of distribution, 
installation, access, and operational control. 


There are many tools to assist you in managing applications on the 
network. The solution that you chose should provide at least the 
following functionality: 


@ Distribution 


The ability to successfully distribute applications from a server to 
multiple clients. 


@ Installation 


The ability to perform necessary configuration management for 
each client an application is deployed to. 


% Operational control 


The ability to execute required control tasks against an 
application, for example, application startup and shutdown, or 
network drive connection. 


Generally speaking, the solution you choose must enhance your ability 
to perform the basic tasks required to manage the entire life-cycle of a 
network application. 


Using NetWare Application Management Tools 


NetWare® 4.11 provides application management software that helps 
you set up and manage network applications from a single 
administrative console through Novell Directory Services™ (NDS™). 


The software is comprised of a NetWare Administrator tool referred to 
as NetWare Application Manager™ (NAM™) and a client tool referred 
to as NetWare Application Launcher™ (NAL™). 


The NetWare application management tools enables management of 


the application lifecycle, beginning with distribution and installation to 
configuration and upgrades. 
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Using NetWare Application Manager 


The NetWare Application Manager (NAM) software assists you in 
setting up and managing network applications from the NetWare 
Administrator. 


Using NetWare Administrator, an administrator creates Application 
objects in NDS for any application to make it available through the 
NetWare Application Launcher (NAL). Rights to these application 
objects can then be assigned to containers, groups and users. 


Using the NetWare Application Launcher 


The NetWare Application Launcher (NAL). NAL is a user application 
that leverages NDS to offer users easy access to applications stored on 
the network. 


NAL offers easy distribution, updating, version control and license 
management for applications stored on the network. NAL also offers 
fault tolerance for the application environment. 


When a user running NAL logs in through Novell Directory Services, 
NAL looks at the groups and containers the user belongs to and 
recognizes any applications that the user is authorized to access. 


In the background, NetWare Application Launcher locates all the user’s 
applications on the network and accesses them transparently when the 
user selects the program icon in Windows. An NAL program group 
displays all the appropriate application icons that the user can select to 
launch the application. 


Available applications are scanned and updated automatically for the 
user. 


Users don’t need to worry about drive mappings, paths, or rights to the 


application directories. The administrator can manage the application 
launcher on a Container, Group, or User object level. 
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Understanding the Benefits of NetWare Application Management Tools 


The NetWare Application Manager and NetWare Application Launcher 


1. 


Simplify administration of network applications 


The user cannot delete the application icon or change any of its 
information. 


Eliminate the need for login scripts 


The administrator can associate working directories, paths to 
executable files, or other information with the Application object. 


Simplify user access to network applications 


The users can log in to the network using any workstation and can 
still access all their applications. 


Dynamically update user desktops 


The users are unaware of any changes if the administrator wants 
to move or rename the executable file. Only the object itself must 
be modified. 


Ease installation and upgrades 


Users can run installation programs from the NetWare 
Application Launcher, allowing them to install software such as 
NetWare Client™ software, productivity software, and operating 
systems over the network. An application can be upgraded by 
modifying the path to the new application executable, which can 
be installed anywhere on the network. 


Easy to install and use 


Steps for installing the NetWare Application Manager are easy to 
follow and to complete. Launching the NetWare Application 
Launcher is as easy as double-clicking an icon. 


For information on how best to use NAL and NAM in your network, 
see the online help provided through the NetWare Administrator help 
menu or see Setting Up and Using NetWare Application Management 
Software,” in Chapter 2 of Supervising the Network. 
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Identifying Efficient Licensing and Metering Tools 


NetWare 4.11 also provides NetWare Licensing Services (NLS) that 
enables you to monitor and control the use of licensed applications on 
a network. 


Metering Applications 


Application metering software controls the number of people who can 
simultaneously access a network application. This type of software 
helps you use an application within the limits of the software license. 


Licensing Applications 


Almost all legitimate computer software use is regulated by an explicit 
license. The license typically states who may use the software and 
under what conditions. There are many different types of licenses, each 
of which reflects the intended use of the software. 


Until recently, software use licenses were often nothing more than a 
printed license statement included in the product’s packaging. Software 
vendors relied on the integrity of their customers to not violate the 
license; in many cases, this was sufficient to protect the vendor’s 
investment in developing the software. 


However, in an attempt to further reduce losses that result from illegal 
software distribution and use, a group of software developers have 
written the License Service Application Programming Interface 

(LS API). The License Service API allows license servers to 
communicate with client applications via the API making applications 
essentially self-metering. 


Key to the automatic enforcement of license agreements is a third 
component called the access token, or digital license certificate. The LS 
API contains the specification of the industry standard License Service 
API, or LS API for this component. 


Using NetWare Licensing Service 
NetWare Licensing Service (NLS) is the means provided by Novell by 


which applications that are written to the LSAPI specification can be 
managed in a NetWare environment. 
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NetWare 4.11 provides NLS.NLM which offers a standard server 
component for developers to write to. The NLS technology provides 
more active enforcement of application license agreements. NetWare 
4.11 can now function as a licensing server giving developers more 
control over how applications are being used. 


To take advantage of NLS, the software on your network must 
incorporate the LSAPI specification. For information on whether the 
software you use is written to the LSAPI specification, contact the 
appropriate software vendor. 


Managing Application Licenses 


NetWare Licensing Service is a distributed, enterprise network service 
that enables administrators to monitor and control the use of licensed 
applications on a network. 


NLS is tightly integrated with Novell Directory Services (NDS) and is 
based on an enterprise service architecture. This architecture consists of 
client components that support different platforms and system 
components that reside on NetWare 4.11 servers. 


Metering Application Use 


NLS also provides a basic license metering tool, as well as libraries that 
export licensing service functionality to developers of other licensing 
systems. 


NLS Components 


NLS also provides a basic license metering tool, as well as libraries that 
export licensing service functionality to developers of other licensing 
systems. 


NLS consists of the following components: 

% One or more License Service Providers loaded on NetWare 4.11 
servers. An LSP server is a NetWare 4.11 server with the NLS 
NetWare Loadable Module™ (NLS.NLM) loaded. 

% By default, when you install NLS, an LSP Server object is created 


in the Directory that represents the LSP server. The LSP Server 
object is placed in the same context as the NetWare Server object 
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+ 


+ 


that represents the NetWare 4.11 server on which you installed the 
NLM. 


Platform-specific client components NLS supports DOS, 
Windows*, Windows 95*, and NetWare 4.11 NLM clients 


Novell Directory Services (NDS) 


Transaction databases 


For information on how best to use NLS in your network, see the online 
help provided through the NetWare Administrator help menu and 
“Managing NetWare Licensing Services ” in Chapter 10 ofSupervising 
the Network. 


Application Management Guidelines 


The following guidelines should be followed when designing a 
application management strategy: 


1. 
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Install all applications under the same username, such as the 
ADMIN User object. This keeps ownership consistent and 
manageable. Be aware that there are some applications that check 
for the SUPERVISOR user, not an equivalent. 


Observe the license restrictions on all software. 


Take advantage of UNC (Universal Naming Convention) path 
names and Novell Directory Services. By using UNC path names, 
workstations reference the server and volume, not a drive letter. 
This reduces the number of drive connections and enables you to 
change server names by leaving and Alias object for the server in 
the Directory tree. 


Use the MAP ROOT command to support programs that require 
a root directory. 


Use Directory Map objects to ease access to programs and 
applications. 


Summary 


6. Use NetWare Application Manager and NetWare Application 
Launcher to ease distribution, installation, and access to network 
applications. 


7. Ensure that application directories have efficient access control. 
Assign Read and Files Scan rights to application groups or users. 
Use the FLAG utility to assign Read-Only and Shareable attributes 
to program files. 


Efficient planning decreases the amount of time necessary to manage 
application installation, distribution, and configuration. 


Using some simple guidelines and efficient management tools can 
greatly reduce the amount of time and effort needed to manage 
applications. 


Where to Go from Here 








If you want to Go to 
Create a migration strategy for Chapter 9, “Developing a Migration 
servers and workstation from a Strategy,” on page 193 


previous version of NetWare or other 
network operating system 





Create an implementation schedule Chapter 10, “Creating an 
Implementation Schedule,” on 
page 223 
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chapter 9 


Developing a Migration Strategy 


Existing NetWare® networks and networks based on non-NetWare 
operating systems should develop a strategy to ensure an efficient and 
trouble-free migration of network data to NetWare 47M, 


This chapter describes the process used for developing a migration 
strategy for your network. 


The following topics are discussed on the indicated pages: 

@ “Determining a Client Migration Method” on page 195 

@ “Determining a Server Migration Method” on page 203 

e “Setting Up a Lab” on page 216 
If you are installing a new network, you do not need to develop a 
migration strategy. Continue to the next procedure. See Chapter, 
“Creating an Implementation Schedule,” on page 226 for more 
information. 
You might want to review information about setting up a test lab for 
integration testing of hardware and software applications if your 
network environment meets any of the following requirements: 

@ More than thirty NetWare 4 servers 


@ More than 2000 users 


See “Setting Up a Lab” on page 216 for more information. 
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Introduction 


Objectives 


Creating an efficient migration strategy is important to the success of 
your NetWare 4 implementation. By doing so, you can successfully 
transition existing network resource settings and data to NetWare 4. 


The transition between previous versions of NetWare and other 
network operating systems to NetWare 4 is simple and automatic. Tools 
are provided to assist you. 


An efficient migration strategy requires you to develop strategies for 
@ Client workstation migration 
% Server migration 


Other factors that will affect the success of your implementation should 
be managed through lab testing and setting up a pilot system. These 
factors are: 


@ Software compatibility 
@ Hardware compatibility 


By testing these factors in a lab setting, the team will have more time to 
familiarize themselves with the new operating system and utilities. 


You should develop an efficient strategy for migrating client 
workstations and network servers, select the best migration method for 
your particular network environment, and then test the compatibility of 
network software and hardware by setting up a test lab and pilot 
system. 


Use resource maps, location maps, LAN and WAN topology maps, 
installation and configuration information, backup schedules, and 
workflow information to determine the best strategy to use to for 
migrating NetWare 4. 
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Prerequisites 


A VÁ l] You should have copies of the following documents: 


Physical maps 

Logical maps 

Installation information 
Configuration information 
Backup schedule 


+» ©% ©% . . + 


Workflow information 


Determining a Client Migration Method 


NetWare 4 supports the following client types: 
@ DOS and Windows* 

e OS/2* 

% Macintosh* 

e NFS* UNIX* 


NetWare 4 provides full NDS support for DOS and Windows clients 
running the 16-bit NetWare DOS Requester™ software and the Client 
32™ software. Full support is also provided for OS/2 clients running 
the OS/2 NetWare Requester™ software. The NetWare DOS Requester 
and OS/2 NetWare Requester support all of the migration and 
administration utilities. 


NetWare 4 provides full Novell® Directory Services™ (NDS™) support 
for Macintosh clients. However, no NDS-aware Macintosh utilities are 


currently available for administering the network. 


NetWare 4 provides full bindery-based login for NFS clients. All 
resources are accessed through bindery services. 
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Migrating Client Software before Installing NetWare 4 


You should migrate all client workstations to NetWare 4 before 
migrating NetWare server platforms. If you are migrating client 
workstations connected to non-NetWare servers, wait until the server 
data is migrated before installing the NetWare client software on those 


workstations. 


Identifying Critical Factors 





Topic 


Consider the following when migrating client workstations: 


Condition 


Decision 





Protocols 


The protocols and frame 
types of your network affect 
the client software 
configuration. 


NetWare 4 supports the default frame type for 
Ethernet_802.2 as opposed to the previous 
setting of Ethernet_802.3. NetWare 4 also 
supports IP and IPX protocols running 
simultaneously or separately. Decide which 
frame types and network protocols will be used. 





User context 


A default context is set in the 
NET.CFG file for DOS, 
Windows, and OS/2 
workstations. 


NetWare clients for DOS, Windows, and OS/2 
support the NAME CONTEXT setting in the 
NET.CFG file. This allows workstations to set 
the default setting for the user context when 
they log in to the network. 





Workstation 
management 


The management software 
used affects the client 
configuration. 


The NetWare Client supports SNMP-based 
management tools. Decide if you will load the 
NetWare client support for SNMP. 





Workstation backup 


The backup software used 
on the network affects the 
client configuration. 


The NetWare Client supports target services 
agents (TSA) for SMS-based backup engines. 
Decide if you will load the NetWare Client 
support for SMSTSA. 





Security 


Networks that require a high 
level of security might need 
additional configuration. 


The NetWare Client supports RSA encryption 
and packet signature functionality. Decide if 
your network requires this level of security. 





Backwards 
compatibility 


Some network software and 
hardware were developed for 
bindery services. They might 
require NETX support. 


NetWare Client software supports connectivity 
to bindery-based servers and applications. 
100% compatibility is available for NETX-based 
applications. Decide how many workstations 
must continue to use the NetWare Client shell 
software (NETX). 
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Topic 





Condition Decision 





Coexistence with peer- 
to-peer networks 


Some client workstations are NetWare Client supports connectivity to 
required to connect to other Personal NetWare and NDIS-based networks. 
networks. Decide if DOS and Windows workstations will 


support connectivity to Personal NetWare and 
other NDIS-based networks. 





Performance 


All workstations benefit from NetWare Client software allows for Large 
performance tuning the client Internet Packets (LIP) and Packet Burst. 
software. Decide if all workstations require the 


performance increase. 





Novell provides the following client software for the different types of 


workstations: 
@ NetWare Client 32 for DOS and Windows 
@ NetWare Client 32 for Windows 95 
@ NetWare Client for DOS and Windows 
@ NetWare Client for OS/2 
@ NetWare Client for Mac OS 
@ NetWare Client for Windows NT* 








NetWare Client for Windows NT software is not included in NetWare 
4.11. You can obtain a copy of the NetWare Client for Windows NT 
software from NetWire. See “Supplemental Information” on page 291 
for more information. 


NetWare NFS Services is provided in NetWare 4. This allows UNIX 
client workstations bi-directional access to file and print services 
between UNIX and NetWare Servers. 
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Client Type Description 





NetWare Client 32™ Novell's new 32-bit clients are based on a common, advanced architecture that 

software departs from the NetWare DOS Requester™ software (the VLM™-based client). 
This new architecture enables the client software to run in protected mode. In 
addition, Client 32 requires less than 5 KB of conventional memory, while 
providing a larger cache. 


The Client 32 architecture, designed for robust connectivity and easy 
maintenance, provides the following features: 


+ 





You can distribute Client 32 to the computers on your network using the 
Automatic Client Upgrade utility. 


Client 32 detects changes in a workstation’s network environment and restores 
connections to the network when the relevant network service is restored. This 
makes Client 32 the most reliable NetWare client available. And, when a 
computer loses its connection to the network, the computer continues to run 
without having to reboot. 


Client 32 caches frequently used data, such as file content and network 
information, resulting in less traffic on the network and faster response times 
on the client. 


Client 32 supports multiple Directory tree access and complete Novell 
Directory Services access. 


Client 32 can use 32-bit or 16-bit LAN drivers. Client 32 supports the following 
LAN drivers: 


. 32-bit ODI LAN drivers that comply with the latest NetWare driver 


specifications (Some certified drivers for NetWare 4.1 are compatible with 
Client 32.) 


. 16-bit ODI LAN drivers 


. 32-bit and 16-bit Network Device Interface Specification (NDIS) adapter 


drivers (NetWare Client 32 for Windows 95 only) 
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Client Type 





Description 





NetWare Client for 
DOS and Windows 


With NetWare 4, Novell introduced a new DOS client architecture called the 
NetWare DOS Requester software. The NetWare DOS Requester software 
replaced the NetWare shell (NETX.EXE) and is sometimes referred to as the 
VLM-based client. 


The NetWare DOS Requester software consists of individual modules that are 
loaded as needed to perform specific functions for the client. For example, 
NWP.VLM establishes and maintains connections, logins, and logouts; FIO.VLM 
handles file input and output; REDIR.VLM provides DOS redirection services. 


The VLM Manager (VLM.EXE) controls memory allocation and communication 
among individual VLMs and applications. 


With NetWare 4.11, the NetWare DOS Requester software has been enhanced in 
the following ways: 


+ Using the Automatic Client Upgrade feature, you can easily upgrade 
workstations using the NetWare DOS Requester software to the new NetWare 
Client 32 for DOS and Windows software. 


e With the 16-bit version of the NetWare Application Launcher utility, 
workstations using the NetWare DOS Requester software can access 
Application objects in the Directory. 


+ The NetWare DOS Requester software has been enhanced to comply with the 
Controlled Access implementation (Class C2) requirements of the Trusted 
Network Interpretation [NCSC-TG-005] of the Trusted Computer System 
Evaluation Criteria [DoD5200.28-STD]. 


+ Aversion of the NetWare DOS Requester software that includes support for a 
16-bit TCP/IP transport, the Dynamic Host Configuration Protocol (DHCP), and 
the NetWare/IP software is included with NetWare 4.11. 
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Client Type Description 





NetWare Client for The NetWare Client for OS/2 software enables OS/2 workstations to connect to 
OS/2 NetWare networks. With NetWare 4.11, the NetWare Client for OS/2 software has 
been enhanced to include the following features: 


+ The software supports full NDS connectivity during Global DOS and Windows 
sessions. You no longer need to load NETX during a DOS session to get a 
bindery connection to a server running NetWare 4. Full NDS connectivity is not 
possible, however, during private DOS or Windows sessions. 


+ With the “DISCONNECT ON” parameter in the NET.CFG file and the 
NWSTART and NWSTOP utilities, you can control network connectivity during 
the system boot process. When an OS/2 workstation boots up with the 
“DISCONNECT ON” parameter in the NET.CFG file, the NetWare Client 
software is loaded but no network connections are made. To establish a 
network connection, use the NWSTART utility. To suspend your network 
connections, use the NWSTOP utility. 


+ The software now supports an enhanced mode IPX/SPX interface during 
Windows sessions. Because the enhanced mode interface incorporates the 
standard mode interface too, you no longer need to load TMBI2 support during 
Windows-0OS/2 sessions. 


+ NetWare Client for OS/2 now uses the same standard, cross platform 32-bit 
NetWare Client libraries that the clients based on Client 32 use. 
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Client Type 





Description 





NetWare Client for 
Mac OS 


The new NetWare Client for Mac OS software enables workstations using the Mac 
OS to communicate with a network via the IPX or IP transport protocols instead of 
or in addition to the AppleTalk protocol. This enables you to use a single protocol 
on a network that includes workstations using the Mac OS and other NetWare 
clients. 


In addition, the NetWare Client for Mac OS software enables a Mac OS-based 
workstation to do the following: 


+ 


You can browse a Novell Directory Services tree and log in to Novell Directory 
Services, change passwords, log out, and manage Directory connections. The 
NetWare Client for Mac OS software fully supports simultaneous connections 
to multiple Directory trees. 


The software communicates via the AppleTalk, IPX, or TCP/IP transports. You 
can use AppleTalk, IPX, and TCP/IP atthe same time. In addition, the NetWare 
Client for Mac OS software fully supports connections to NetWare/IP networks. 


Workstations using the NetWare Client for Mac OS software can access 
NetWare volumes that do not have the Mac name space or AppleTalk Filing 
Protocol NLMs loaded; however, they are limited to the 8.3 DOS file naming 
format. 


You can mount a NetWare volume on the Macintosh desktop, and you can 
access files stored on a NetWare server and use a NetWare printer or queue. 


You can open one or more remote connections to one or more NetWare server 
consoles. 
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Client Type 


Description 





NetWare Client for 
Windows NT 


(The NetWare Client 
for Windows NT 
software is not 
available in the 
NetWare 4.11 
package. Contact a 
NetWare customer 
representative for 
information on 
obtaining copies of 
the software.) 


The NetWare Client for Windows NT allows Windows NT workstations to integrate 
into NetWare networks. Users can log in to their NT workstation once and access 
all the services on their NetWare network. 


The NT client software includes support for NDS, enabling NT client workstations 
to take advantage of all of features of NDS, including transparent access to all the 
resources on the network, regardless of where they are physically located. The 

product runs on both Windows NT 3.1 and 3.5 and includes the following features: 


+ Full NDS support 


+ 


Access to NetWare file and print services through NT File Manager and NT 
Print Manager 


+ 


Support for both ODI™ and NDIS 32-bit server LAN drivers (all NetWare 4.1 
certified server LAN drivers are supported) 


+ 


Support for both IPX™ and NetWare IP transport protocols for accessing 
NetWare services 


+ 


Compatibility with any DOS or Win16 application for backward-compatibility 


+ NetWare support for NT long file naming through Novell’s HPFS name space 


Automating the Client Migration Process 


You can automate the migration process for existing NetWare client 
workstations by using batch files or the Automatic Client Upgrade 
(ACU) instead of the INSTALL.EXE program. 


Using Batch Files 


These batch files can be placed in a container login script that runs the 
batch file programs for each workstation at login. 


Create batch files to: 
% Copy core NetWare Client files 
% Copy standardized operating system startup files 


% Copy standardized NetWare Client startup files 
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@ Copy standardized NetWare Client configuration files 


@ Upgrade the operating system version 
Using the Automatic Client Upgrade (ACU) 
With NetWare 4.11, you can use the Automatic Client Upgrade (ACU) 


feature to easily migrate a set of network clients. The following table 
summarizes the upgrade scenarios that ACU is designed to address. 


From. To 





Workstations using the 16-bit The NetWare Client 32 for DOS and 
NetWare DOS Requester software Windows software 


Workstations using an outdated The latest version of the NetWare 
version of the NetWare Client 32 for Client 32 for Windows 95 software 
Windows 95 software 


Workstations using a version of The latest version of Novell’s 
Microsoft’s Client for NetWare NetWare Client 32 for Windows 95 
Networks software 


For complete information on using the Automatic Client Upgrade 
feature, see the help system for the NetWare Client 32 for DOS and 
Windows or NetWare Client 32 for Windows 95 software (depending on 
the software to which you want to upgrade). 


Determining a Server Migration Method 


Novell® supplies a number of options for upgrading earlier versions of 
the NetWare” operating system (NetWare 2, 31M, and 4™) to 

NetWare 4.11. The upgrade option you use is dependent on a number 
or variables which include 

% Your present version of NetWare 


% Your hardware, including servers and clients 


% Your intention of maintaining an existing server, or migrating 
bindery and data to a new server 
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Identifying Upgrade Methods 


There are four ways to migrate to NetWare 4.11: 
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Upgrade Using INSTALL.NLM 


This option allows you to maintain the NetWare 3.1x or 4.x 
computer as a server by upgrading the operating system to 
NetWare 4.11. 


If you are upgrading from a NetWare 3.1x server, the server is 
placed in a context within a NetWare 4 Directory tree. 


NetWare 4.11 requires a volume SYS: of at least 75 MB. If your 
NetWare 3.1x or 4.x server’s volume SYS: is smaller than 75 MB, 
and you want to maintain the computer as a server, you must 
perform a Same-Server Migration. 


Upgrade Across-the-Wire Using the DS Migrate Utility 


This option is for those who have an existing NetWare 2.1x, 2.2, or 
3.1x server and want to migrate the server bindery and data 
across-the-wire to an existing NetWare 4.11 server using a the DS 
Migrate utility. 


This option allows you to see and refine a model of your updated 
Directory tree before completing its migration. 


Then, you can migrate the server files using MIGRATE.EXE (for 
NetWare 2.1x, or 2.2 servers) or the new NetWare File Migration 
utility (for NetWare 3.1x servers). 


Upgrade Using the “Across-the-Wire” Option of MIGRATE.EXE 


Like the DS Migrate utility option, this allows you to migrate 
NetWare 2.1x, 2.2, or 3.1x server bindery and data files across-the- 
wire. 


This option is included for those users who are already familiar 
with the MIGRATE.EXE utility from previous versions of 
NetWare, and for users who must migrate NetWare 2.1x or 2.2 
data. 


The bindery is migrated to a DOS workstation where it is stored 
temporarily on the workstation’s hard disk. The server files are 
migrated directly to the NetWare 4.11 server. 


Once all files have been migrated, the bindery is copied to the 
NetWare 4.11 server where it becomes part of the NetWare 4 
Directory tree. 


This option does not include modeling capabilities and is done 
through a text-based user interface rather than a GUI. 


@ Upgrade Using the “Same-Server” Option of MIGRATE.EXE 


This is for those who have an existing NetWare 2.1x, 2.2 or 3.1x 
server, who want to upgrade the server itself to a NetWare 4.11 
server, but cannot use INSTALL.NLM because 


+ The server is a NetWare 2.1x or 2.2 server (NetWare 2 servers 
cannot load INSTALL.NLM) 


+ Volume SYS: is too small (NetWare 4.11 requires a minimum 
volume SYS: of 75 MB) 


+ The DOS partition is too small (NetWare 4.11 requires a 
minimum DOS partition of 15 MB) 


+ Any hardware modifications have to be made to the server 


Once your NetWare server files have been backed up to a backup 
device, this option allows you to use MIGRATE.EXE to migrate 
your NetWare 2.1x or 3.1x server bindery so you can then install 
the NetWare 4.11 operating system on your server. 


Once the NetWare 4.11 operating system is installed, you restore 
the files and then use MIGRATE.EXE to migrate the bindery back 
to the upgraded server. The bindery information becomes part of 
the new NetWare 4 Directory tree. 


Identifying Other Upgrade Options 


The options discussed above are the principal options used to upgrade 
to the NetWare 4.11 operating system. Novell continues to provide and 
support other network operating system upgrade options. These 
include: 


e Asolution for upgrading NetWare 3 and 4 LANs and WANs using 
RCONSOLE. 
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% An in-place upgrade option for upgrading a NetWare 2 server to 
NetWare 4.11 using the 2XUPGRDE.NLM (available on 
NetWire®). 


@ The UIMPORT utility. This is provided to allow you to import 
Directory information from another database to Novell Directory 


Services. 


@ Tools for migrating non-NetWare operating systems to 
NetWare 4.11 (available through Novell Consulting Services). 


@ Additional upgrading tips and ideas (available through Novell 
Consulting Services). 


Maintaining Backwards Compatibility 


You should upgrade all NetWare 4 servers to NetWare 4.11 for 
performance and administrative advantages. 


However, during migration to NetWare 4.11, different versions of 


NetWare 4 and NetWare 3 will still interoperate. NetWare 4 networks 
support this by offering bindery services and NetSync. 
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Maintaining Bindery Services in a NetWare 4 Environment 


moray 


Some applications, services, and clients that run in the NetWare 4 
environment do not currently take full advantage of Novell Directory 
Services technology. To enable users of these services to access them 
from the NetWare 4 environment, Novell offers bindery services. 


With bindery services, NDS imitates a flat structure for leaf objects 
within an Organization or Organizational Unit object. Thus, when 
bindery services is enabled, all objects within the specified container 
can be accessed by NDS objects and by bindery-based servers and client 
workstations. 


Bindery services applies only to leaf objects in the specified container object. 


Setting a Bindery Context 


Figure 9-1 
Bindery Services in 
a Directory Tree 


To enable bindery services, use the “SET BINDERY 
CONTEXT=complete_name parameter by using the SET command or the 
SERVMAN server utility. (See “SERVMAN” in Utilities Reference.) The 
container object you indicate with the SET BINDERY CONTEXT 
parameter is called the bindery context. 


The following figure illustrates bindery services when an 
Organizational Unit object is specified as the bindery context. 
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A writable replica of the partition that includes the container object to 
be set as the bindery context must be stored on each server you want 
bindery services enabled on. 


However, by default, only the first three servers installed on a partition 
receive a replica of the partition during the installation process and 
subsequently support bindery services. 


You can add replicas to other servers if needed for bindery services. If a 
read/write or master replica is not present, use the NDS Manager or 
PARTMGER utility to add one to the server. For information and 
procedures, see “Placing Replicas for Bindery Services” on page 101. 


Important If a bindery context is not set, Novell Directory Services (NDS) cannot support 
vV bindery services. 


Setting Multiple Bindery Contexts 


Ideally, all objects a user wants to access under bindery services should 
be located in the same bindery context. However, this is not always 
possible or practical. 


You can set multiple bindery contexts for users who need to access 


objects outside of their own bindery contexts. For example, consider the 
Directory tree in the following figure. 


208 Place Book Title Here 


Figure 9-2 
Multiple Bindery Contexts 
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[ROOT] US United States 
Country MFG Manufacturing 


Organization HQ Head Quarters 


Organizational Unit HR Human Resources 


Common Name PROD Production 





To set bindery contexts on the servers HO_SRV1 and HO_SRV2 in this 
figure, you would enter the following command in the server’s 
AUTOEXEC.NCF file where the users are located: 


SET BINDERY CONTEXT=ACCT.HQ.ACME;PROD1. 
DETROIT.MFG.ACME; TEST.DETROIT.MFG.ACME; 


To set multiple bindery contexts, you must set the contexts to include 
the path all the way to the [Root] of the tree. You can set up to 16 
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contexts per server. Use semicolons to separate the complete names of 
the containers that you want a bindery context set to. 


Warin = Do not change a server’s bindery context once you set it. Changing a server's 
Y bindery context prevents all bindery services users (from the original context) 
who need to log in to that server from accessing bindery services. Changing the 
server’s bindery context can also disable access to print queues. 


Bindery services allows NetWare 4 servers to emulate earlier versions 
of NetWare and is, therefore, server-centric. For instance, if a client 
workstation requests a bindery login, bindery services directs the 
default server to use the bindery login script found in the user's mail 
directory on the SYS: volume instead of using the user’s global NDS 
login script. Changes to the bindery login script are kept locally and are 
not distributed to other servers. 


You cannot disable bindery services if someone is logged in via bindery 
services, and bindery objects are always available unless bindery 
services is disabled. 


Planning Bindery Services 


When you plan and implement bindery services, you need to consider 
the following. 


Created Objects 
Keep these guidelines in mind as you plan bindery services: 


@ Ifyou require the user GUEST, or if you use a service that requires 
GUEST, you must create such a user in the Directory database. 


% During installation, a bindery object SUPERVISOR is created but 
is not used with NDS. The NDS utilities do not display this object. 
This object is intended to be used with bindery services and to 
enable access to the server via a bindery login. Once bindery 
services is enabled, you can use this object to log in to the server, 
providing you log in as a bindery object. You can create an NDS 
User object SUPERVISOR and assign ADMIN-equivalent rights to 
itin NDS. However, the bindery object and the Directory object 
are unique and separate objects even though they are identified by 
the same name. 
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% After installing NetWare Services, you can use a migration utility 
to convert bindery user accounts to Directory User and Group 
objects. If you do, all users except SUPERVISOR and all groups are 
updated to Directory objects. The user SUPERVISOR is migrated, 
but with supervisory rights for that server’s file system and 
bindery context only. The supervisor does not appear as an 
Directory object. 


Inaccessible Information 
Some NDS information is not available to users through bindery 
services. This information includes, but is not limited to, the following 
items: 

@ E-mail name 

@ Phone number 

@ = Print job configurations 

@ = Aliases 


@ Profiles 


@ NDS login scripts 


Limited Partitioning 


The bindery context for a server can be set to a container that is part of 
a partition stored on a different server. But, before you can use bindery 
services, you must place a writable replica of the partition that includes 
the bindery context on the bindery services-enabled server. 


If you set the bindery context for a server to a container object that is not 
part of a writable replica on that server, users will not be able to log in 
via bindery services. 


For more information, see “Placing Replicas for Bindery Services” on 
page 101. 
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Maintaining NetWare 3 Servers Using NetSync 
NetSync synchronizes NetWare 3 users and groups with Directory 
objects in specific NetWare 4 server bindery contexts. When you update 
or create a user or group on the NetWare 4 server, the NetWare 4 server 
synchronizes the information with the NetWare 3 servers in the 
NetSync cluster. The user or group now exists on all the NetWare 3 
servers in the cluster. 
Setting up NetSync allows you to 

@ Upgrade NetWare 3 print services to NetWare 4 


@ Administer NetWare 3 servers, users, and groups with NetWare 4 
utilities 


@ Maintain up to 12 NetWare 3 servers in a NetSync cluster 


@ Remove NetWare 3 servers from a NetWare Naming Service 
(NNS) domain for migrating to Novell Directory Services (NDS) 


Determining When to Use NetSync 
You should use NetSync for either of the following two reasons: 
% You want to access and manage existing NetWare 3 users, groups, 
and print queues services from NetWare 4 and do not plan 


upgrading the NetWare 3 server. 


% You want to remove a NetWare 3 server from a NetWare Naming 
Service (NNS) domain 


Determining When to Not Use NetSync 
You should not use NetSync for any of the following reasons: 
@ You only have NetWare 4 servers in your network 


% You are upgrading all NetWare 3 servers to NetWare 4 and 
migrating the user and group accounts, and print services 


% You plan to manage the NetWare 3 servers outside of your 
NetWare 4 network 
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For more information about setting up and using NetSync, see Installing 
and Using NetSync. 


Maintaining a Mixed NetWare 4 Environment 


You should upgrade all NetWare 4 servers to NetWare 4.11 for 

performance and administrative advantages. However, during 
migration to NetWare 4.11, different versions of NetWare 4 and 
NetWare 3 will still interoperate. 


Maintaining a mixed NetWare 4 environment will require some special 
maintenance to ensure the correct version of NDS.NLM is being used. 
Furthermore, you will need to understand some specific partitioning 
limitations when distributing partitions across mixed NetWare 4 
servers. 


Checking Your Novell Directory Services Version 


The NDS base schema has been modified in NetWare 4.11. The new 
schema is compatible with DS.NLM version 4.89 and later, and the 
DS.NLM versions supported in NetWare 4.02. 


You can check which version of DS.NLM you are loading by going to 
the server console and typing 


MODULES <Enter> 
A sample might appear as follows: 


DS.NLM 
NetWare 4.1 Directory Services 
Version 4.94 December 14, 1995 


Copyright 1993-1996 Novell, Inc. All rights 
reserved 


The sample above indicates that the NetWare 4.1 server is using 
DS.NLM version 4.94. 


Chapter 9: Developing a Migration Strategy 213 


If Then 





You are upgrading a NetWare 4.0x On the NetWare 4.11 

server Operating System CD-ROM, go to 
the 
PRODUCTSINW402Vanguage_direc 
tory and refer to the instructions in the 
READUPGD.TXT and 
DSREPAIR.DOC files. 





You are upgrading a NetWare 4.1 On the NetWare 4.11 

server that is running a DS.NLM Operating System CD-ROM, go to 

version prior to 4.89 the PRODUCTS\NW410\/anguage 
directory and refer to the instructions 
in the READUPDS.TXT file. 


Important To avoid NDS base schema conflicts, always upgrade the server holding the 
vV master replica of the [Root] partition first. 


Maintaining Replicas in a Mixed NetWare 4 Environment 


To maintain proper synchronization among NetWare 4 servers of 
different version, first upgrade servers that hold a replica of the [Root] 
partition in a tree to NetWare 4.11. 


When upgrading NetWare 4.0x servers to NetWare 4.1x, the following 
rules apply to the Add, Split, Join, and Remove Partition operations and 
to the Change Replica Type operations: 


1. Ifthe master replica of a partition resides on a NetWare 4.0x 
server, all partition operations can be performed in a mixed 
environment. 


2. Once the master replica of a partition has been moved to a 
NetWare 4.1x server, the master replica can't be moved back to a 
NetWare 4.0x server. 


3. You cannot perform the Add, Split, and Join Partition operations 
for that partition until all servers are upgraded to NetWare 4.1x, or 
until the NetWare 4.0x servers that have partition replicas have 
had those replicas removed. 
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4. Ifa master replica of a partition resides on a NetWare 4.1x server, 
the Add, Split and Join Partition operations won't work if the 
NetWare 4.0x server contains a subordinate reference of the 
partition. 


5. The Remove Partition operation always works regardless of the 
master replica’s location. 


6. The Change Replica Type operation works in a mixed 
environment except when the master replica has been moved to a 
NetWare 4.1x server. In this case the master replica can only be 
moved to another NetWare 4.1x server. However, you can only 
change replicas of a partition on servers running earlier versions 
of NetWare 4 to read/write or read-only. 


The following matrix shows which partition operations are possible in 
a mixed environment. 


The master replica column indicates the NetWare version on the server 
containing the master replica. 














Partition Operations Support for All NetWare 4 Versions 

Operation Master replica On a NetWare 4.01 On a NetWare 4.02 Ona NetWare 4.1x 

Add replica NetWare 4.01 OK OK OK 
NetWare 4.02 OK OK OK 
NetWare 4.1x Not OK Not OK OK 

Change replica NetWare 4.01 OK OK OK 

wpa NetWare 4.02 OK OK OK 
NetWare 4.1x OK OK OK 

Join partition NetWare 4.01 OK OK OK 
NetWare 4.02 OK OK OK 
NetWare 4.1x Not OK Not OK OK 
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Table 9-1 


Partition Operations Support for All NetWare 4 Versions 











Operation Master replica On a NetWare 4.01 On a NetWare 4.02 On a NetWare 4.1x 
Remove partition NetWare 4.01 OK OK OK 

NetWare 4.02 OK OK OK 

NetWare 4.1x OK OK OK 
Split partition NetWare 4.01 OK OK OK 

NetWare 4.02 OK OK OK 

NetWare 4.1x Not OK Not OK OK 





Setting Up a Lab 


You should set up a lab should be set up to install, configure, and test 
NetWare 4.11 for your particular network environment. It will provide 
the hands-on experience important to developing an efficient migration 
strategy and implementation of NetWare 4. 


The hardware and software should be representative of the existing 
network environment. Try to use similar network boards, LAN 
topology, and workstation operating systems. At least one CD-ROM 
player should be included for installing the NetWare 4 software on the 
initial server. 


The lab environment should not affect the current operation of the 
existing network but should maintain a connection to the current 
network backbone. This will allow for migration and backward 
compatibility testing. 


Using NetWare 4.11 Utilities 


A full suite of utilities is provided for implementing NetWare 4. These 
utilities include NetWare Loadable Module (NLM) programs for the 
server and utilities for the workstation. 


The NetWare 4 utilities support Windows, OS/2, DOS, and Macintosh, 
and NFS* UNIX environments. 
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earlier versions of utilities and NLM programs do not always correspond to 


y Because of differences between Novell Directory Services and the bindery, 
NetWare 4 utilities and NLM programs. 


Server Utilities and NLM Programs 


With NetWare 4.11, there are two types of utilities used at the server 
console: 


@ Command line utilities 


Command line utilities are executed by typing the command as 
described in the NetWare 4 Utilities Reference manual. 


@ NetWare Loadable Module™ (NLM) programs (typically, menu- 
based utilities) 


NLMs must be loaded from the server console prompt by typing 
the LOAD command followed by the NLM filename. 


A lists of all server utilities included with NetWare 4.11 and those that 
are new or updated since NetWare 3.1x. is available in Utilities Reference. 


NetWare Workstation Utilities 
In NetWare 4.11, there are three types of utilities used at a workstation: 


@ DOS command line utilities 


DOS command line utilities are executed by typing the command 
at a DOS prompt on a workstation or from within a login script or 
batch file as described in the NetWare 4 Utilities Reference manual. 
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DOS menu-based utilities 


DOS menu-based utilities are executed by typing the name of the 
utility at a DOS prompt on a workstation. 


Graphical utilities 


Graphical utilities are run from within the Windows 3.1, Windows 
95, or OS/2 environments. 


A lists of all server utilities included with NetWare 4.11 and those that 
are new or updated since NetWare 3.1x. is available in Utilities Reference. 


Analyzing Hardware and Hardware Driver Compatibility 


Analyzing network hardware and hardware drivers allows you to 
determine what versions of drivers are being used and which operating 
systems these drives can support. Many manufacturers have developed 
specific hardware drivers for NetWare 4. Contact the hardware 
manufacturers for copies of the latest version of hardware drivers and 
information about product support. 


Establishing a Pilot System 


A pilot system provides a testing environment for evaluating and 
analyzing compatibility of network utilities and applications with NDS 
and bindery services. The following factors should be evaluated and 
analyzed: 


+ 
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NetWare 4.11 installation options 


Run the installation program to familiarize yourself with the 
various installation options. The process is simple; however, you 
might need to add new programs or additional licenses. Novell’s 
online documentation is installed through the installation utility. 
Client diskettes are also created with the installation program. 


Initial Directory tree creation 


The Directory tree foundation is created during the installation 
process. You should test your tree design by creating the actual 
tree structure that was developed during the design process. 
Ensure that you use the naming standards for your organization 
and create actual container and leaf objects that will exist in your 
network environment. Only the [Root] Organization object and 


first level of Organizational Unit objects are created with the 
installation utility. All other objects are created with NetWare 
Administrator or NETADMIN. 


Time synchronization configuration 


The first server installed into the Directory tree is a Single 
Reference time server. The second and following servers installed 
into the tree are Secondary time servers. Once all the lab servers 
are installed, you should configure time synchronization for each 
lab server according to the established time synchronization 
strategy. 


Use the SERVMAN server utility to change the time server setting 
if needed. 


Partition and replica creation 


The [Root] partition is automatically created on the first NetWare 
4 server during installation. Use NDS Manager or PARTMGR to 
create partitions and replicas in the tree. The number of servers in 
your lab environment depends on how many partitions and 
replicas can be created. 


Application testing 


Perform application testing to ensure compatibility between 
existing network environments and NetWare 4.11. Test client and 
server applications and the NetWare 4.11 and third-party 
applications that are used on your network. 


See “Application Compatibility” on page 277 for a copy of a 
template you can use to perform your testing. 


Backup and restore procedures 


The backup and restore process used on your network should be 
tested and evaluated for NetWare 4.11. Ensure that your backup 
utility is updated to perform both NetWare 4.11 data and NDS 
backup. 
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Summary 


Client installation or migration 


Three options are available for installing or migrating client 
workstations to NetWare 4.11. These methods are: floppy diskette, 
CD-ROM, or across-the-wire. Identify which method you will use. 
Test any automation processes or configurations. The NET.CFG 
files for DOS, Windows, and OS/2 workstations should be tested 
and optimized. 


An efficient migration strategy for client workstations and servers will 
make the implementation process straightforward. The lab 
environment will give you the hands-on experience you need to 
effectively implement NetWare 4.11. 


Evaluation 


You should ensure that the following procedures have been 
accomplished before continuing: 


1. 
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Your migration plan for client workstations and servers maintains 
some identifiable procedures. 


Responsibility for each implementation procedure has been 
assigned to a team member. 


Strategies include configuration concerns for all network 
workstation types. 


Individual server concerns are identified and a migration method 
is decided for each. 


Adequate testing has been done to ensure seamless integration 
and compatibility. 


Where to Go from Here 


To 





Go to 





Perform interoperability testing with 
NetWare 4 applications 


Configure and troubleshoot 
interoperability testing for NetWare 4 


Develop a schedule for implementing 
NetWare 4 on your network 


Implement NetWare 4 on your 
network 


“NetWare 4.1 CIT Interoperability 
Testing Overview,” Novell Application 
Notes, Jan 95 (Novell part no. 164- 
000047-001) 


“NetWare 4.1 Interoperability Test 
Configurations and Troubleshooting,” 
Novell Application Notes, Jan 95 
(Novell part no. 164-000047-001) 


Chapter 10, “Creating an 
Implementation Schedule,” on 
page 223 


Chapter 11, “Implementing NetWare 
4 Services,” on page 229 
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chapter 


Introduction 


1 0 Creating an Implementation 


Schedule 


If you have an existing NetWare® network, networks based on non- 
NetWare operating systems, or complex networks, you should create an 
implementation schedule to ensure that the implementation of 
NetWare 4 is as troublefree and efficient as possible. 


This chapter describes how to create an implementation schedule for 
your implementation of the NetWare 4™ operating system. 


The following topics are discussed: 
e “Identifying Tasks and Assignments” on page 224 
@ “Determining an Efficient Implementation Schedule” on page 225 


If you have a new network with only one server, you do not need to 
create an implementation schedule. Continue to the next procedure. See 
Chapter 11, “Implementing NetWare 4 Services,” on page 229 for more 
information. 


A smooth implementation of NetWare 4 requires adequate planning to 
manage the various implementation phases. A well-planned 
implementation eliminates confusion, provides efficient execution of 
tasks, and communicates migration tasks. 


Create a schedule to provide the necessary planning that your system 
needs. Some networks will develop a very short schedule and others 


may carry over a few months. 


An efficient schedule gives you a timeline for the entire implementation 
process and determines the individual tasks that need to be completed. 
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Objectives 
You should 
1. Clearly identify the tasks that need to be accomplished. 
2. Assign resources to execute the task. 
3. Plan when the tasks will be started and finished. 


Doing so will ensure that network client workstations and servers can 
continue to operate uninterrupted. 


This enables you to organize your schedule by tasks and identify the 
general tasks needed to perform the implementation process. 


Prerequisites 


Checklist l] You should have copies of the following planning documents: 
Vv + Resource maps 
+ Location maps 
+ LAN and WAN topology maps 
+ Directory tree design 


Identifying Tasks and Assignments 


Identifying tasks and assignments requires you to create a task list and 
then assign these tasks. 


Creating a Task List 
For each implementation task, your implementation schedule should 
include the task description, start date, target end date, the person 


assigned, and the percentage of completion. 


Once the schedule is created, it can be used to set deadlines, measure 
the progress of tasks, review the work, and produce reports. 
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When creating a task list, consider the following elements of the 
implementation process: 


% Client software migration or installation and configuration 
@ Server installation and configuration 

@ Directory tree design 

@ Access and security strategy 

@ Time synchronization strategy 

% Partition and replication plan 


@ File and print services setup and configuration 


Assigning Task Responsibilities 


Once an implementation task list is created, then each task should be 
assigned to a person or team that is responsible for completion of the 
task. A person or team might be responsible for more than one task in 
the list. 


The task owner should ensure that the person or team responsible for 
the task is familiar with the procedures and utilities necessary for 
completing their assignments. 


Determining an Efficient Implementation Schedule 


Scheduling Tasks 


An efficient implementation schedule lays a foundation for improved 
communication and predictability by allowing you to visualize the 
implementation tasks in relationship to each other. This perspective 
allows you to reduce the amount of rework needed to manage the 
project effectively, and to deal assertively with issues that may arise. 


You should identify a projected start and end date for each task. This 
allows the project team to better manage the sequence of 
interdependent tasks and workflows. 
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Tracking Progress 


You must coordinate schedules with other groups in your organization. 
This will ensure that all groups are informed of the changes that will 
occur and allow them to train and prepare for each step of the 
implementation process. 


Project tracking provides a clear indication of the project status and 
helps ensure a high level of communication about the progress of each 
task. Project tracking also allows the project team lead to address issues 
quickly and assertively before they become problems that may hinder 
progress. 


Creating an Implementation Schedule Draft 


Summary 


Your team should draft a project schedule for implementing NetWare 4. 
The draft should include at least the following elements: 


@ A listing of each project task 

% A description of each task 

@ The owner of each task 

% A beginning and end date for each task 
% A status indicator for each task 


See “Implementation Schedule” on page 279 to view an example of an 
implementation schedule. 


Creating an efficient implementation schedule requires you to complete 
the following tasks: 


% Make a list of all the tasks necessary for implementing NetWare 4 
@ Match each task with the appropriate resource 


% Determine appropriate timelines and milestones 
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Where to Go from Here 








To Go to 
Implement NetWare 4 on your Chapter 11, “Implementing NetWare 
network 4 Services,” on page 229 
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chapter 1 1 


Introduction 


Objectives 


Implementing NetWare 4 Services 


This chapter describes the process used for implementing the 
NetWare® 4™ operating system. 


The following topics are discussed: 
@ “Completing General Tasks” on page 230 


+ “Implementing NDS on Various Network Types” on page 234 


Implementing the Novell® Directory Services™ (NDS™) technology on 
your network can be as simple or complex as you want it to be. The 
flexibility of NDS allows you to install and run it on a single server or 
many servers. 


You should 
1. Clearly understand the tasks that need to be accomplished 
2. Know which resources are assigned to execute each task 
3. Know when each task will be started and finished 


By meeting these objectives, you will ensure that network client 
workstations and servers can continue to operate uninterrupted. 


This will enable you to complete the implementation smoothly and on 
schedule. 
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Prerequisites 


JA VA Lj 


You should have copies of the following planning documents: 
Resource maps 

Location maps 

LAN and WAN topology maps 

Directory tree design 

Accessibility plan 

Partition and replica worksheet 


+ ©% >% è è è o 


Implementation schedule 


Completing General Tasks 


To implement NDS on your network, you need to first complete the 
following general tasks: 


1. 
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Install the first server and set up the Directory tree. 


When you install NetWare 4, the INSTALL utility automatically 
installs Novell Directory Services and prompts you to name the 
[Root] with the tree name. Then you can create and name an 

Organization object and up to three Organizational Unit objects. 


You must then set the server context within the Directory tree. If 
you want to participate in the information superhighway, add a 
country code when setting the server context and a Country object 
will be created directly below the tree name or [Root] object. 


The network hardware supports both file services and Novell 
Directory Services. If you add large numbers of leaf objects, such 
as users or print queues, to a single container, you might need to 
increase the amount of memory on that NetWare server to 
improve performance. 


Migrate workstations 


With the client software, you can upgrade network clients without 
modifying your existing server configurations. Your users will 
retain connectivity to all versions of NetWare. Once your client 
workstations are migrated to the latest client software, your 


NetWare servers can be systematically migrated to NetWare 4 
without interrupting user access to any server on the network. 


With the NetWare Client software, you can install only the 
connectivity options needed on any workstation. For small 
networks, users can choose their optimal configuration to 
minimize memory use and maximize performance. For large 
network environments, you can establish a common 
configuration for multiple workstations. 


Use NetWare Administrator or NETADMIN and PCONSOLE to 
complete the setup. 


NetWare Administrator is a Windows-based utility, and 
NETADMIN and PCONSOLE are DOS-based utilities. To run 
these utilities, you must first install and set up a DOS or Windows* 
client workstation. 


Then, you can set up the remaining Directory tree structure, create 
objects for all network resources you want available in the 
Directory database, and create Profile objects for maintenance 


purposes. 


Leaf objects. Place leaf objects in containers that provide the best 
access for the resources, groups, and users that use them. 


For example, a NetWare Server object that stores a replica of each 
partition on the network can be placed in an Organization object 
for more efficient network management. Other servers and print 
queues can be placed in Organizational Units with the users or 
groups that use them. 


Profile objects. Create Profile objects that provide organization or 
department login scripts in the appropriate container objects for 
groups of users who need similar work environments but who are 
not located in the same container object. 


Implementing objects this way allows for easy, centralized control 
at the top of the tree and local control of the lower levels. At each 
container level, a User object with supervisory rights has 
authority over the objects within that container object. 


Chapter 11: Implementing NetWare 4 Services 231 


232 Place Book Title Here 


Add new servers to appropriate contexts. 


To add a new server, first create the container object you want to 
install a new server into by using NetWare Administrator or 
NETADMIN. 


Set the appropriate container and property rights. 


Security features can be set up in NetWare Administrator or 
NETADMIN. 


Configure time synchronization by specifying time 
synchronization parameters for each NetWare server. 


The number and location of container objects, partitions, and 
replicas determine the type of time servers you should create for 
your network. 


Make considerations for, and enable, bindery services by setting 
bindery contexts. 


For security, optimum performance, and reliability, it is a good 
idea to group servers within container objects, depending on 
department or site. If, for example, your organization is spread 
over three cities, specify a site-specific container object as a 
bindery context for the following reasons: 


+ To provide local control over bindery services at each site 


This allows the network supervisors to control local 
administration—updating local servers, adding or deleting 
users, installing new equipment, and performing other tasks 
that are often best handled on a local basis. 


+ To improve security 


If, for example, network supervisors in three different cities 
have supervisor rights over the same container object 
(bindery context), each of them can assign rights that the 
other two would disagree with. 


+ To decrease traffic over WAN links 


If, for example, users in London and Tokyo had their User 
objects in a bindery context served by a server in New York, 
every data transmission would take place over WAN links. 
This would likely result in decreased performance and 
create the potential for other problems. 


To enable bindery services for objects within a container 
object, you need to set a bindery context to that container. 


8. Optimize and manage Directory trees. 


Use NDS Manager or PARTMGR to manage the Directory 
databases on your network. 


Partitions. Create most of your partitions at lower levels of the 
Directory tree. Workgroup boundaries generally determine the 
number of partitions required in a tree. You should partition your 
tree in relation to the use and physical locations of network 
resources. You should create partitions only if they provide better 
performance or fault tolerance to the network and tree. 


Before performing any partition operation, ensure that the state of 
synchronization for all servers affected by the operation is stable. 
The following table provides recommendations for determining 
which partitions will be affected by what operation: 








Partition Operation Partitions Affected 

Create, add, delete a partition Target partitions 

Change the replica type Target partitions 

Rebuild any partition replica Target partitions 

Join partitions Parent and child partitions 


Chapter 11: Implementing NetWare 4 Services 233 


Replicas. Do not create too many replicas of the [Root] partition 
and other parent partitions. If you do, you force NDS to keep track 
of more child partition references than necessary. The appropriate 
number of replicas for any given partition depends on your 
environment. 


If you create your Directory tree with the network user and 
resources in mind, you will find that the most efficient use of 
replicas—reducing WAN traffic while providing fault tolerance— 
means you should not need many replicas. 


Implementing NDS on Various Network Types 


The following discussions outline the recommended implementation of 
NDS features and functionality specific for single-site, multiple-site, 
and multiple-campus networks. You must decide which method or 
combination of methods best suits your organization’s particular needs 
and requirements. 


Single-Site Network 


Implementing NDS on a single-site network is typically based on two 
possible models: 


@ The physical location of network resources 
@ The departmental structure of the organization 
The following figure shows a Directory tree in which ACCT 


(Accounting), HR (Human Resources), and PAY (Payroll) represent 
departments, all under the Organization HQ (Headquarters). 
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Figure 11-1 
Example of a Single-Site Directory Tree 
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Directory Tree Structure 


Single-site networks are commonly site-, workgroup-, and department- 
oriented in structure. They are easily managed by a system-wide 
administrative group with central management at the organizational 
and departmental levels. 


The Directory tree begins with a single Organization object with few or 
no Organizational Unit objects below. If Organizational Units exist, they 
are based on functional groups, projects, and departments within a 


single site. 


Resources are usually shared by all network users and groups. 
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Time Services 


Although a single-site business might be restricted to a single- or 
multiple-segment LAN, time services is still important. 


A Single Reference time server is usually adequate for LAN-based 
networks. The Single Reference time server is monitored and 
periodically adjusted for time by the network supervisors. 


All other servers in the network are designated as Secondary time 
servers. 


Partitions 


Workgroup boundaries generally determine the number of partitions 
required in a tree. You should partition your tree in relation to the use 
and physical location of network resources. You should create 
partitions only if they provide better performance or fault tolerance to 
the network and tree. Single-site networks may not require partitioning. 


If you think it is necessary, create a small number of partitions at the top 
levels of the tree. 


Replicas 
Each server on the network should contain all the resources needed for 


the users that it services. You should copy two to three replicas of each 
partition somewhere on the network to provide fault tolerance. 


Multiple-Site Network 
Implementing NDS on a multiple site network is typically based on 
your business’ organizational chart with some geographic 


considerations for branch offices. 


The following figure shows an example of a common Directory tree for 
a multiple-site network. 
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Figure 11-2 < [Root] Partition | 
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Directory Tree Structure 


Time Services 


Multiple-site networks are commonly workgroup and department 
oriented in structure. They are typically managed by a central, system- 
wide administrative group and department network supervisors. 


The Directory tree begins with a general Organization object with 
multiple Organizational Unit objects below. Organizational Units are 
based on functional groups, projects, departments, etc. 


In the Organization object and high-level Organizational Units are 
enterprise resources that are managed centrally. For example: 


@ Servers that function as SAA* or TCP/IP gateways or as a 
NACS™ system 


@ User objects for network supervisors 


@ Profile objects that create an environment for specific users and 
groups 


Create User objects for centralized supervisors and Organizational Unit 
object supervisors within their respective container objects. The 
Organizational Unit object-level supervisors are often department 
network supervisors. 


Centralized supervisors are responsible for general network 
management and overall support for the Directory tree. Organizational 
Unit-level supervisors are responsible for day-to-day tasks, such as 
User object and resource management and local server backup. 


Centralized management helps facilitate the implementation of 
network-wide standards. You should create and distribute a standards 
document for the entire network before implementing NDS. 


Because many multiple-site networks maintain some level of WAN 
connectivity, time services support is an important consideration. 


A Single Reference time server is usually inadequate for networks that 
have WAN connections. You should use a group of Primary time 
servers as the basis for network time services. 
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Partitions 


Replicas 


Determine which servers within your organization provide system- 
wide services, such as directories or applications accessed by multiple 
departments or the entire organization. 


Choose a limited number from the group of servers you identified to be 
installed as Primary time servers. Limiting the number of Primary time 
servers to a few minimizes the network traffic used when the time 
servers vote on the current time. Typically, you should have one or two 
Primary time servers at each location on the network. 


Set up remaining servers as Secondary time servers. 


Partitioning multiple-site networks should follow the structure of your 
Organizational Unit objects. You might want to create a partition for 
each high-level Organizational Unit in the tree. 


This allows each partition to contain all of the resource objects that a 
particular department needs to access. Place the [Root] and 
Organization objects in the same partition. 


Create replicas to ensure adequate redundancy of critical partitions. 
Determine which servers within your organization provide system- 
wide services, such as applications accessed by multiple departments 
or the entire organization. 


Place replicas of the partitions that include these critical servers on 
other servers in different locations on the network. This allows all users 
to authenticate to an enterprise resource without increasing network 
traffic. 


For servers that provide local services, place replicas of the partitions 
that include them on other local servers. 


If only one server exists at a location, place a replica of the partition that 


includes the server on a server in a different location. Provide 
additional replicas if possible. 
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Multiple-Campus Network 


Multiple-campus networks are enterprise focused, linking large, 
organizational networks with many other equal- or smaller-sized 
networks. They require flexibility, advanced security, and centralized 
management of distant resources as well as local supervision. 


The following figure shows an example of a Directory tree for a 
multiple-campus network. 
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Figure 11-3 
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Directory Tree Structure 


The Directory tree begins with a general Organization object with 
multiple Organizational Unit objects below. Organizational Units are 
based on functional groups, projects, and departments and also on site 
locations such as cities or countries. 


Multiple-campus networks typically require both system-wide 
administrative groups with central management at the organizational 
and departmental levels and site-based administrative groups that 
manage local resources and objects. 


Multiple-campus networks typically have a number of high-level 
divisions within the organization that form the top level of 
Organizational Units. Most of these divisions are divided into sub- 
departments which form a second level of Organizational Units. A third 
level of Organizational Units might consist of locations or functional 
groups. 


Organizational and Departmental Containers 


Organization and Organizational Unit objects contain enterprise 
resources that are managed centrally. For example: 


@ Servers that function as SAA* or TCP/IP gateways or as a 
NACS™ system 


@ User objects for network supervisors 


@ Profile objects that create an environment for specific users and 
groups 


Centralized Management 

As organizations grow, it is necessary to maintain the workgroup and 
departmental structure of an organization while sufficiently increasing 
the centralized administration. 

You should create User objects for centralized supervisors and 
Organizational Unit-level supervisors within their respective container 


objects. 


Centralized supervisors are responsible for general network 
management and overall support for the Directory tree. Organizational 
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Time Services 


Unit-level supervisors are responsible for day-to-day tasks, such as 
User object and resource management and local file server backup. 


Centralized management also helps facilitate the implementation of 
network-wide standards. You should create and distribute a standards 
document for the entire network before implementing NDS. 


Because most multiple-campus networks maintain high levels of WAN 
connectivity, which span time zones and international datelines, time 
services support requires careful planning. 


It is critical to have a constant reference of time in order for NDS 
synchronization to take place. Time is also important to the proper 
execution of certain events and features, such as network backups and 
time-based security. 


You should use one Reference time server and a group of Primary time 
servers as the basis for network time services in a time provider group. 
This ensures that a proper and accurate time reference is available at all 
times. 


Determine which servers within your organization provide system- 
wide services, such as directories or applications accessed by the entire 
organization. From the servers you identify, select one to function as the 
Reference time server and set up the others as Primary time servers. 


Each geographically distinct site should have at least one Primary time 
server. 


All other NetWare servers in the network should be set up as Secondary 
time servers. 


The Reference time server should be adjusted periodically by an 
outside time source. 
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Partitions 


Partitioning of multiple-sized networks should follow a multitiered 
partition plan. 


Each division-level Organizational Unit has its own partition 
representing that container and its objects. Each lower-level 
Organizational Unit is the root for a partition that includes itself and all 
the other container and leaf objects beneath it in that branch of the tree. 


The [Root] and Organization objects should form one partition. This 
partitioning structure ensures that all of the critical access points in the 
tree are available and can be replicated for redundancy. 


Replicas 


Create replicas to ensure adequate redundancy of critical partitions. 
Determine which servers in your organization provide system-wide 
services, such as applications accessed by multiple departments or the 
entire organization. 


Place replicas of the partitions that include these critical servers on 
other servers in different locations on the network. This allows all users 
to authenticate to an enterprise resource without increasing network 
traffic. 


For servers that provide local services, place replicas of the partitions 
that include them on other local servers. 


If only one server exists at a location, place a replica of the partition that 
includes the server on a server in a different location. Provide 
additional replicas if possible. 


For added security and fault tolerance, place a read /write replica of 
each partition on a server at the Organization object level of each 
Directory tree. This enables the central network management staff to 
maintain a complete Directory database in one location. 


Make sure that every partition has a sufficient number of replicas 


available on the network, including replicas on appropriate distant 
servers, to ensure fault tolerance and to decrease WAN link traffic. 
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Summary 


Most replicas should be located on servers in the main corporate 
network, except for other locations that have multiple servers. In these 
cases, replicas of the appropriate partitions are located on all of these 
servers. 


Implementing NetWare 4.11 requires you to complete the following 
tasks: 


1. 


10. 


Finalize and use any planning documents you have created to 
make a list of the Directory objects you will install. 


Sort Directory objects by location. 
Sort objects into a logical hierarchy. 
Install the first server and set up the Directory tree. 


Use NetWare Administrator or NETADMIN and PCONSOLE to 
complete the setup. 


Add new servers to appropriate contexts. 
Set the appropriate container and property rights. 


Configure time synchronization by specifying time 
synchronization parameters for each NetWare server process. 


Make considerations for, and enable, bindery services by setting 
bindery contexts. 


Optimize and manage Directory trees. 
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appendix A i i 
NDS Object Classes and Properties 


Overview 


This appendix explains the object classes and properties available in the 
Novell® Directory Services™ architecture. 


“y Some Novell documents use the term attributes and properties interchangeably. 
v 
The following topics are discussed: 
@ “NDS Object Classes and Their Functions” on page 247 


@ “NDS Object Classes and Their Properties” on page 250 


NDS Object Classes and Their Functions 


This section lists the most common NDS object classes, explains what 
each is used for, and indicates where that type of object can be 





contained. 
Table A-1 
Object Class, Function, and Possible Containment 
Object Class Function Possible Container 
AFP Server Represents an AppleTalk* File Protocol- None 


based server that is operating as a node on 
your NetWare® network—and possibly also 
acting as a NetWare router to, and as the 
AppleTalk server for, several Apple* 
Macintosh* workstations 
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Table A-1 continued 


Object Class, Function, and Possible Containment 





Object Class 


Function 


Possible Container 








Alias Redirects the path of the Directory tree Depends on the 
branch or leaf object to another location for containment rules 
more convenient access mandated by the 

object class to 
which the Alias 
object points 

Audit File Defines container and volume audit trails Organization 


Organizational Unit 





Bindery Object 


Represents an object upgraded from a 
bindery-based server that cannot be mapped 
to a Directory object 


Organization 
Organizational Unit 














Bindery Queue Represents an object that has been created None 
by bindery services to emulate user-defined 
Queue objects 
CommExec Represents a class used in NetWare MHS None 
services 
Computer Represents network computers that are not Organization 
file or print servers (such as gateways, Organizational Unit 
routers, and sometimes workstations) 
Country Defines an additional level of organization in Root level 


the Directory tree 





Directory Map 


Represent the physical name of the file 
system directory path 


Organization 
Organizational Unit 





Device 


Represent physical units that can 


communicate, such as a modem, printer, etc. 


Organization 
Organizational Unit 





External Entity 


Used by services (Such as messaging) to 
store information about entities (such as 
e-mail users) outside of the Directory 


Organization 
Organizational Unit 








Group Defines an unordered list of users that Organization 
comprise a group for the purpose of Organizational Unit 
assigning access rights 

List Defines an unordered set of names without Organization 


implying security equivalence 


Organizational Unit 
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Table A-1 continued 


Object Class, Function, and Possible Containment 





Object Class 


Function 


Possible Container 





Locality 


Defines geographical locations in the 
Directory tree 


Country 

Locality 
Organization 
Organizational Unit 





Message Routing Group 


Represents a group of messaging servers 
with direct connectivity for transferring 
messages between any two of them 


Organization 
Organizational Unit 





Messaging Server 


Represents a server that picks up messages 
submitted by messaging applications or 
transferred from another messaging server 


Organization 
Organizational Unit 





NetWare Server 


Represents a server that provides file and 
other services 


Organization 
Organizational Unit 





Organization 


Defines an organization in a network 


Country, Root, or 
Locality level 





Organizational Role 


Defines a position or role in an organization 
for the purpose of assigning access rights 


Organization 
Organizational Unit 





Organizational Unit 


Defines a subdivision in an organization to 
contain objects 


Organization 
Organizational Unit 





Print Server 


Represents a network print server 


Organization 
Organizational Unit 

















Printer Represents a physical printing device on Organization 
network Organizational Unit 
Profile Specifies a login script used by several users Organization 
Organizational Unit 
Queue Represents a batch processing queue for Organization 
printing on the network Organizational Unit 
Unknown Represents any object created by the server None 
to restore an object whose base class is no 
longer defined by the schema 
User Represents a user on the network Organization 


Organizational Unit 
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Table A-1 continued 
Object Class, Function, and Possible Containment 


Object Class Function Possible Container 





Volume Represents a physical volume in a NetWare Organization 


server Organizational Unit 





NDS Object Classes and Their Properties 


This section lists the most common Directory object classes and the 
properties associated with each. 


Table A-2 


Object Class and Properties 


Object Class and Properties 





AFP Server 
Unique to Class 


Serial Number 
Supported Connections 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


CN (Common Name) 
(Inherited from Server) 


Account Balance 

Allow Unlimited Credit 
Descriptions 

Full Name 

Host Device 

L (Locality Name) 
Minimum Account Balance 
Network Address 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Private Key 

Public Key 

Resource 

Security Equals 
Security Flags 

See Also 

Status 

User 

Version 





250 Place Book Title Here 


Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





Alias 
Unique to Class 


Aliased Object Name 


Object Class 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 





Audit File 


Object Class (Inherited from 
Top) 


ACL 

Audit A Encryption Key 
Audit B Encryption Key 
Audit Contents 

Audit Current Encryption Key 
Audit Link List 

Audit Path 


Audit Policy 
Audit Type 

Back Link 
Description 

L (Locality Name) 





Bindery Object 
Unique to Class 
Bindery Object Restriction 


Bindery Type 
CN (Common Name) 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 
CA Private Key 

CA Public Key 


Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 

Last Referenced Time 
Obituary 

Reference 

Revision 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





Bindery Queue 
Unique to Class 


Bindery Type 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


Common Name (Inherited 
from Resouce) 


Description 

Host Resource Name 

L (Locality Name) 

O (Organization Name) 
OU (Organizational Unit 
Name) 

See Also 


Queue Directory (Inherited 
from Queue) 


Device 

Host Server 
Network Address 
Operator 

Server 

User 

Volume 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





CommExec 
Unique to Class 


Network Address Restriction 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


CN (Common Name) 
(Inherited from Server) 


Account Balance 

Allow Unlimited Credit 
Descriptions 

Full Name 

Host Device 

L (Locality Name) 
Minimum Account Balance 
Network Address 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Private Key 

Public Key 

Resource 

Security Equals 
Security Flags 

See Also 

Status 

User 

Version 





Computer 
Unique to Class 


Operator 
Server 
Status 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


CN (Common Name) 
(Inherited from Device) 


Descriptions 

L (Locality Name) 
Network Address 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Owner 

See Also 

Status 

Serial Number 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





Country 
Unique to Class 


C (Country Name) 
Description 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 


Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 

Last Referenced Time 
Obituary 

Reference 

Revision 





Directory Map 
Unique to Class 


Host Server 
Path 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


CN (Common Name) 
(Inherited from Resouce) 


Descriptions 

Host Resource Name 

L (Locality Name) 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Owner 

See Also 
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Table A-2 continued 
Object Class and Properties 


Object Class and Properties 





External Entity 
Unique to Class 
CN (Common Name) 


Description 

EMail Address 

External Entity 

Facsimile Telephone Number 
L (Locality Name) 

Mailbox ID 

Mailbox Location 


OU (Organizational Unit 
Name) 

Physical Delivery Office 
Name 

Postal Address 

Postal Code 

Postal Office Box 

S (Street or Province Name 
SA (Street Address) 
See Also 

Title 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 





Group 
Unique to Class 
CN (Common Name) 


Description 

EMail Address 

Full Name 

GID (Group ID) 

L (Locality Name) 
Login Script 

Mailbox ID 

Mailbox Location 
Member 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Owner 

Profile 

Profile Membership 
See Also 


Object Class (Inherited from 


Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





List 
Unique to Class 
CN (Common Name) 


Description 

EMail Address 

Full Name 

Mailbox ID 

Mailbox Location 
Member 

O (Organization Name) 
OU (Organizational Unit 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 





N 
one Obituary 
See Also Reference 
Revision 
Locality Object Class (Inherited from 


Unique to Class 


Description 

L (Locality Name) 

S (Street or Province Name 
SA (Street Address) 

See Also 


Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 
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Table A-2 continued 
Object Class and Properties 


Object Class and Properties 





Message Routing Group 
Unique to Class 


None 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


CN (Common Name) 
(Inherited from Group) 


Description 

EMail Address 

Full Name 

GID (Group ID) 

L (Locality Name) 
Login Script 

Mailbox ID 

Mailbox Location 
Member 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Owner 

Profile 

Profile Membership 
See Also 





Messaging Server 
Unique to Class 


Message Routing Group 
Messaging Database 
Location 

Messaging Server Type 
Postmaster 

Supported Gateway 
Supported Services 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


CN (Common Name) 
(Inherited from Server) 


Account Balance 

Allow Unlimited Credit 
Description 

Full Name 

Host Device 

L (Locality Name) 
Minimum Account Balance 
Network Address 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Private Key 

Public Key 

Resource 

Security Equals 
Security Flags 

See Also 

Status 

User 

Version 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





NetWare Server 
Unique to Class 


DS Revision 
Message Server 
Operator 
Supported Services 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


CN (Common Name) 
(Inherited from Server) 


Account Balance 

Allow Unlimited Credit 
Description 

Full Name 

Host Device 

L (Locality Name) 
Minimum Account Balance 
Network Address 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Private Key 

Public Key 

Resource 

Security Equals 
Security Flags 

See Also 

Status 

User 

Version 





Organization 
Unique to Class 
O (Organization Name) 


Description 

Detect Intruder 

EMail Address 

Facsimile Telephone Number 
Intruder Attempt Reset 
Interval 

Intruder Lockout Reset 
Interval 

L (Locality Name) 

Lockout After Detection 


Login Intruder Limit 
Login Script 

Mailbox ID 

Mailbox Location 

NNS Domain 

Physical Delivery Office 
Postal Address 

Postal Code 

Postal Office Box 

Print Job Configuration 
Printer Control 

S (State or Province Name) 
SA (Street Address) 
See Also 

Telephone Number 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





Organizational Role 
Unique to Class 


Description 

EMail Address 

Facsimile Telephone Number 
L (Locality Name) 

Mailbox ID 

Mailbox Location 

OU (Organizational Unit 
Name) 

Physical Delivery Office 
Name 

Postal Address 

Postal Code 

Postal Office Box 

Role Occupant 

S (State or Province Name) 
SA (Street Address) 

See Also 

Telephone Number 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 





Organization Unit 
Unique to Class 
OU (Organization Unit Name) 


Description 

Detect Intruder 

EMail Address 

Facsimile Telephone Number 
Intruder Attempt Reset 
Interval 

Intruder Lockout Reset 
Interval 

L (Locality Name) 

Lockout After Detection 


Login Intruder Limit 
Login Script 

Mailbox ID 

Mailbox Location 

NNS Domain 

Physical Delivery Office 
Postal Address 

Postal Code 

Postal Office Box 

Print Job Configuration 
Printer Control 

S (State or Province Name) 
SA (Street Address) 
See Also 

Telephone Number 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





Print Server 


Unique to Class 


Object Class (Inherited from 
Top) 


CN (Common Name) 
(Inherited from Server) 





ACL Account Balance 
Operator Authority Revocation Allow Unlimited Credit 
Printer Backlink Description 
SAP Name Bindery Property Full Name 
CA Private Key Host Device 
CA Public Key L (Locality Name) 
Certificate Revocation Minimum Account Balance 
Certificate Validity Interval Network Address 
Cross Certificate Pair O (Organization Name) 
Equivalent To Me OU (Organizational Unit 
Last Referenced Time Name) 
Obituary Private Key 
Reference Public Key 
Revision Resource 
Security Equal To 
Security Flags 
See Also 
Status 
User 
Version 
Printer Object Class (Inherited from CN (Common Name) 


Unique to Class 


Cartridge 

Default Queue 

Host Device 

Memory 

Network Address Restriction 
Notify 

Operator 

Page Description Language 
Print Server 

Printer Configuration 
Queue 

Status 

Supported Typefaces 


Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


(Inherited from Device) 


Description 

L (Locality Name) 
Network Address 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Owner 

See Also 

Serial Number 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





Profile 
Unique to Class 


CN (Common Name) 
Login Script 


Descriptions 

Full Name 

L (Locality Name) 

O (Organization Name) 
OU (Organizational Unit 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 

Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 





Beas Equivalent To Me 
Last Referenced Time 
Obituary 
Reference 
Revision 
Queue Object Class (Inherited from CN (Common Name) 


Unique to Class 


Device 

Host Server 
Network Address 
Operator 

Server 

User 

Volume 


Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


(Inherited from Resource) 


Description 

Host Resource Name 

L (Locality Name) 

O (Organization Name) 
OU (Organizational Unit 
Name) 

Owner 

See Also 
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Table A-2 continued 


Object Class and Properties 


Object Class and Properties 





Unknown 


Unique to Class 


Object Class (Inherited from 
Top) 


Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 





Ñ ACL Equivalent To Me 
one Authority Revocation Last Referenced Time 
Backlink Obituary 
Bindery Property Reference 
CA Private Key Revision 
CA Public Key 
User Password Unique Required CN (Common Name) 


Unique to Class 


Account Balance 

Allow Unlimited Credit 
Group Membership 

Higher Privileges 

Home Directory 

Language 

Last Login Time 

Locked By Intruder 

Login Allowed Time Map 
Login Disabled 

Login Expiration Time 
Login Grace Limit 

Login Grace Remaining 
Login Intruder Address 
Login Intruder Attempts 
Login Intruder Reset Time 
Login Maximum 
Simultaneous 

Login Script 

Login Time 

Message Server 

Minimum Account Balance 
Network Address 

Network Address Restriction 
Password Allow Change 
Password Expiration Interval 
Password Expiration Time 
Password Minimum Length 
Password Required 


Password Used 
Print Job Configuration 
Printer Control 
Private Key 

Profile 

Profile Membership 
Public Key 
Security Equal To 
Security Flags 
Server Holds 

Type Creator Map 
UID (User ID) 


Object Class (Inherited from 
Top) 


ACL 

Authority Revocation 
Backlink 

Bindery Property 

CA Private Key 

CA Public Key 
Certificate Revocation 
Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 
Last Referenced Time 
Obituary 

Reference 

Revision 


(Inherited from Person) 
Surname 


Description 

Full Name 
Generational Qualifier 
Glven Name 

Initials 

See Also 

Telephone Number 


None (Inherited from 
Organizational Person) 


EMail Address 

Facsimile Telephone Number 
L (Locality Name) 

Mailbox ID 

Mailbox Location 

OU (Organizational Unit 
Name) 

Physical Delivery Office 
Name 

Postal Address 

Postal Code 

Postal Office Box 

Role Occupant 

S (State or Province Name) 
SA (Street Address) 

Title 
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Table A-2 continued 
Object Class and Properties 


Object Class and Properties 





Volume Object Class (Inherited from CN (Common Name) 
£ Top) (Inherited from Resource) 

Unique to Class 
ACL Description 

Host Server Authority Revocation Host Resource Name 

Status Backlink L (Locality Name) 
Bindery Property O (Organization Name) 
CA Private Key OU (Organizational Unit 
CA Public Key Name) 
Certificate Revocation See Also 


Certificate Validity Interval 
Cross Certificate Pair 
Equivalent To Me 

Last Referenced Time 
Obituary 

Reference 

Revision 
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appendix B 


Overview 


Referencing and Using Leaf Objects 


Directory leaf objects are objects that do not contain any other objects. 
These represent actual network entities such as users, servers, printers, 
and computers. You create leaf objects in a container object. 


This appendix explains the leaf objects available in the Novell® 
Directory Services™ architecture. 


The following topics are discussed: 


+ 


+ 


“Application Leaf Object” on page 266 

“Auditing Leaf Object” on page 266 

“Informational Leaf Object” on page 267 
“Messaging-Related Leaf Objects” on page 268 
“Miscellaneous Leaf Object” on page 270 

“NetWare Licensing Services Leaf Object” on page 271 
“Printer-Related Leaf Objects” on page 272 
“Server-Related Leaf Objects” on page 273 


“User-Related Leaf Objects” on page 275 
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Application Leaf Object 


Table B-1 


This section describes the leaf objects that support the NetWare® 
Application Manager, explains what it is used for, and indicates when 


to use it. 


Application Leaf Object 





Leaf Object 


Function 


Usage Situation 





Application 


NetWare Application Manager allows 
network supervisors to manage 
network applications as Application 
objects in the Novell Directory tree. 


NetWare Application Manager displays 
icons for all available applications in a 
window, and lets the user select on an 
icon to launch an application. Users 
don’t need to worry about drive 
mappings, paths, or rights. 


The network supervisor can manage 
applications at the container, Group, or 
User object level. 


Application objects allow you to 
manage the network more efficiently, 
saving time and effort administering 
applications. 


Application objects simplify 
administrative tasks such as assigning 
rights, customizing login scripts, and 
supporting applications. 





Auditing Leaf Object 


Table B-2 


This section describes the leaf object for auditing network resources, 
explains what it is used for, and indicates when to use it. 


Auditing Leaf Object 





Leaf Object 


Function 


Usage Situation 





Auditing 
File 


The Auditing File Object (AFO) is the 
Novell Directory Services data 
structure used to manage an audit 
trail’s configuration and access rights. 
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An audit utility (such as AUDITCON) 
creates the AFO when you enable 
auditing. The server then checks for 
access rights each time a user 
attempts to access the audit trail. 


Informational Leaf Object 


This section describes the leaf object that exists only to store information 
about network resources, explains what it is used for, and indicates 
when to use it. 








Table B-3 
Informational Leaf Object 
Leaf Object Function Usage Situation 
Computer Represents a nonserver computer on Use this object to store information 
the network, such as a workstation or a about a nonserver computer, such as 
router. its network address, serial number, or 


person the computer is assigned to. 


This object has no effect on the 
operation of the network; it only stores 
information about the computer. 
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Messaging-Related Leaf Objects 


This section describes the leaf objects that are related to the NetWare 
Message Handling Service™ (MHS) system, explains what each is used 
for, and indicates when to use each. 


These objects are created and controlled using the MHS utilities. MHS 


Table B-4 


Services software is available on NetWire®. 


Messaging-Related Leaf Objects 


Leaf Object 


Function 


Usage Situation 





Distribution List 


Represents a list of mail 
recipients. 


Use this object to simplify sending 
mail to recipients. 


For example, you could create a 
Distribution List object called 
Recreation Committee. Anyone 
wanting to send a message to all the 
members in the Recreation 
Committee can simply address the 
message to Recreation Committee, 
rather than to each member. 





External Entity 


Represents a non-native NDS 
object that is imported into NDS 
or registered in NDS. 


NetWare MHS™ Services use 
External Entity objects to 
represent users from non-NDS 
directories to provide an 
integrated address book for 
sending mail. 


MHS Services software is 
available on NetWire. 


If your messaging environment 
contains non-MHS servers, such as 
SMTP hosts, SNADS nodes, or X.400 
MTAs, you might choose to add users 
and lists at these servers to your 
Directory database as External Entity 
objects. 


Adding these objects to the database 
as External Entities adds them to the 
address books of your messaging 
applications. When addressing 
messages, local users can choose 
non-MHS users and lists from a 
directory list. 
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Table B-4 continued 


Messaging-Related Leaf Objects 





Leaf Object 


Function 


Usage Situation 





Message Routing 
Group 


Represents a group of 
messaging servers that can 
transfer messages directly with 
each other. 


MHS Services software is 
available on NetWire. 


Create a Message Routing Group 
when you have two or more 
messaging servers that need to 
communicate with each other. 





Messaging Server 


Represents a messaging server 


that resides on a NetWare server. 


A Messaging Server object is 
automatically created in the 
Directory tree when you install 
NetWare MHS Services on a 
NetWare server. 


MHS Services software is 
available on NetWire. 


Create a Messaging Server (by 
installing NetWare MHS Services ona 
NetWare server) when you need a 
server to handle messaging between 
users and groups on the network. 
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Miscellaneous Leaf Object 


Table B-5 


This section lists the remaining available leaf objects, explains what 
each is used for, and indicates when to use each. 


Miscellaneous Leaf Objects 





Leaf Object 


Function 


Usage Situation 





Alias 


Points to another object in the 
Directory tree and makes it appear 
as if the object that it points to 
actually exists in the Directory tree 
where the Alias object is. 


Although an object appears both 
where it was actually created and 
where an Alias referring to it was 
created, only one copy of the object 
really exists. 


If you delete or rename an Alias, the 
Alias itself (not the object it is 
pointing to) is deleted or renamed. 


Use this object to allow access to an 
object that is in another context. 


For example, you can use an Alias to 
represent a resource, such as a 
special printer, that most users in the 
tree need to access. 


Also, when you move or rename a 
container object in a Directory tree, 
you have the option of creating an 
Alias object in place of the moved or 
renamed object. If you select this 
option, NetWare Administrator 
automatically creates the Alias for you 
and assigns it the same name as the 
original object. 


Creating an Alias object in place of a 
moved or renamed container object 
allows users to continue logging into 
the network and to see the container 
object (and the objects it contains) in 
its original Directory location. 





Bindery Object 


Represents an object placed in the 
Directory tree by an upgrade or 
migration utility. 


It is used by NDS only to provide 
backward compatibility with bindery- 
based utilities. 





Bindery Queue 


Represents a queue placed in the 
Directory tree by an upgrade or 
migration utility. 


It is used by NDS only to provide 
backward compatibility with bindery- 
based utilities. 





Unknown 


Represents an NDS object that has 
been invalidated and cannot be 
identified as belonging to any of the 
other object classes. 


Directory Services utilities rename 
objects that they do not recognize. 
Delete or re-create the correct object 
for the resource. 
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NetWare Licensing Services Leaf Object 


This section describes the leaf object for NetWare Licensing Services 
(NLS), explains what it is used for, and indicates when to use it. 








Table B-6 
NetWare Licensing Services Leaf Object 
Leaf Object Function Usage Situation 
LSP Server When you register an LSP (License A client-specific component packages 
Service Provider) with NDS, an LSP the request and submits it to the 
Server object is created, by default, in nearest connected LSP. 
the same context as the NCP Server ee 
object on which it is loaded. The LSP If the client is not connected to an LSP, 


the client checks the Novell Directory 
database, searching up the Directory 
tree for an LSP Server object. 


Server object can be relocated to 
another context in the Directory. 


An LSP Server object appears only if 
you load the NLS (NetWare Licensing 
Services) NLM program with an -r 
option. 
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Printer-Related Leaf Objects 


This section lists the leaf objects that are related to NetWare print 
services, explains what each is used for, and indicates when to use each. 


These objects are created and controlled using the NetWare print 
utilities. 


Table B-7 
Printer-Related Leaf Objects 





Leaf Object Function Usage Situation 
Print Queue Represents a print queue on the You must create a Print Queue object for 
network. every print queue on the network. 


This object cannot be created with 
NETADMIN. Use the NetWare Administrator 
or PCONSOLE. 





Print Server Represents a network print You must create a Print Server object for 
server. every print server on the network. 


This object cannot be created with 
NETADMIN. Use NetWare Administrator or 





PCONSOLE. 
Printer Represents a physical printing You must create a Printer object for every 
device on the network. printer on the network. 


This object cannot be created with 
NETADMIN. Use NetWare Administrator or 
PCONSOLE. 
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Server-Related Leaf Objects 


This section lists the leaf objects that are related to NetWare servers and 
volumes, explains what each is used for, and indicates when to use 


Table B-8 


each. 


Server-Related Leaf Objects 


Leaf Object 


Function 


Usage Situation 





AFP Server 


Represents an AppleTalk* Filing 
Protocol-based server that is 
operating as a node on your 
NetWare network (and possibly 
also acting as a NetWare router to, 
and the AppleTalk* server for, 
several Apple* Macintosh* 
workstations). 


Create this object when you have an 
AFP server on the network. Use it to 
store information about this server, such 
as its description, location, and network 
address. 


This object has no effect on the 
operation of the network; it only stores 
information about the AFP server. 





Directory Map 


Represents a particular directory in 
the file system. Directory Map 
objects can be especially useful in 
login scripts by pointing to 
directories that contain applications 
or other frequently used files. 


For example, if you have a directory 
that contains DOS 6.0, you will 
probably map a search drive to that 
directory in any login scripts you 
create. Later, if you upgrade to 
DOS 6.2 and rename the directory, 
you have to change the mapping in 
every login script where that search 
mapping appears. 


If you use a Directory Map object, 
you only change the information in 
that object, not in all login scripts. 


Use this object to avoid making changes 
to many login scripts when the location 
of applications changes; instead, you 
change only the Directory Map object. 
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Table B-8 continued 


Server-Related Leaf Objects 











Leaf Object Function Usage Situation 
NetWare Represents a server running Use the NetWare Server object to tie the 
Server NetWare. physical server to the Directory tree. 
; Without this object, you cannot access 
Store information about the server file systems that are on that server's 
in the NetWare Server object's volumes. 
properties, such as the server's 
address, the physical location of If you have a non-NetWare 4 server, you 
the server, and what services it must create this object to be able to 
provides. access those non-NetWare 4 volumes. 
When you create a NetWare Server 
In addition to storing information object for a non-NetWare 4 server, the 
about the NetWare server, the non-NetWare 4 server must be running. 
NetWare Server object affects the 
network in that it is referred to by 
several other objects. 
Volume Represents a physical volume on You can create a Volume object for 





the network. 


In the Volume object’s properties, 
you can enter identification 
information, such as the Host 
server, volume location, etc. You 
can also set restrictions for use of 
the volume, such as space limits for 
users. 
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every physical volume on the network. 
(During installation of NetWare 4 ona 
server, Volume objects are created for 
every physical volume on that server.) 


Use INSTALL to create volumes on 
NetWare 4 servers. 


When a Volume object is created, the 
server name and the volume name 
information is placed in the Volume 
object’s properties. 


You can use the Volume object to 
display information about the directories 
and files on that volume. 


User-Related Leaf Objects 


Table B-9 


This section lists the leaf objects that are related to network users and 
groups, explains what each is used for, and indicates when to use each. 


User-Related Leaf Objects 





Leaf Object 


Function 


Usage Situation 





Group 


Assigns a name to a list of User 
objects that can be located 
anywhere in the Directory tree. 


Create a Group when you have 
many User objects that need the 
same trustee assignments. Rather 
than making many trustee 
assignments, you make just one 
trustee assignment to all the users 
who belong to the group by making 
the trustee assignment to the Group 
object itself. 





Organizational 
Role 


Defines a position or role within an 
organization. 


Create an Organizational Role 
object so that you can assign rights 
to a particular position rather than to 
the person who may occupy that 
position. The occupant may change 
frequently, but the responsibilities of 
that position do not. 


You can assign any user to be an 
occupant of the Organizational Role 
object because every occupant 
receives the same rights that you 
granted to the Organizational Role 
object. 





Profile 


Contains a profile login script. 
When the Profile object is listed as 
a User object’s property, the Profile 
object’s login script is executed 
when that User object logs in. The 
Profile login script executes after 
the system login script and before 
the user login script. 


Create a Profile object for a set of 
users who need to share common 
login script commands but who are 
not located in the same container in 
the Directory tree, or who are a 
subset of users in the same 
container. 
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Table B-9 continued 
User-Related Leaf Objects 





Leaf Object Function 


Usage Situation 





User Represents a person who uses 
your network. 


In the User object properties, you 
can set login restrictions, intruder 
detection limits, password and 
password restrictions, security 
equivalences, etc. 


You must create a User object for 
every user who needs to log in to the 
network. When you create a User 
object, you can create a home 
directory for that user. When you 
create User objects, you can also 
choose to apply a user template to 
the User object that provides default 
property values. 


For users who have NetWare 4 
workstations, you can create the 
User objects anywhere in the 
Directory tree, but the users must 
know their context in order to log in. 
You should create User objects in the 
container where the users will 
typically log in. 


For users who have non-NetWare 4 
workstations, you must create the 
User objects in the container where 
the bindery services context is set for 
the server that they need to log in to. 
(Bindery services is set by default for 
every NetWare 4 server that is 
installed.) Non-NetWare 4 users do 
not need to know their context 
because they log in to the server 
rather than to the Directory tree. 
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appendix C 
Template Examples 


This appendix provides template examples that can be used for 
designing, implementing, and maintaining your NetWare® 4™ 
network. 


You should customize all these templates examples to fit your specific 
network environment. 


The following templates examples are provided on the indicated pages. 
@ “Application Compatibility” on page 277 
+ “Implementation Schedule” on page 279 
@ “Name Standards” on page 281 
@ “NetWare 4 Server Worksheet” on page 283 
@ “Replica Placement Template” on page 286 
@ “Server Migration” on page 287 


@ “Workstation Configuration Worksheet” on page 288 


Application Compatibility 


The following template provides an example of an application 
compatibility template you could use for your network migration. 
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Figure C-1 
Application Compatibility Template 


SoftWare and Version Date Scheduled VLM Tested 


Word Processors 

















Spreadsheets 




















Menu Systems 











Databases 

















Print Servers Software and Hardware Devices (Network Direct Connected) 











Gateways 














Tape Backup Systems 
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Figure C-2 
Application Compatibility Template 


SoftWare and Version Date Scheduled VLM Tested 


Remote Access (Dial In/Dial Out) Systems 











Host Connectivity 














Other Specific Programs 
































Implementation Schedule 


The following template provides an example of an implementation 
schedule template. 
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Figure C-3 
Implementation Schedule Template 


t “mer E Target Percent 
Task Title and Description Owner Begin Date End Date Complete 
Complete hardware setup (servers, workstations, 
cabling, routers, bridges, switches, peripherals) 





Install online documentation 





Prepare existing servers for migration 





Install and configure first server (Name the 
Directory tree and setup time synchronization) 





Install or migrate client workstations 


Setup and configure administration utilities 





Setup the Directory tree structure 





Implement your partition strategy 





Install or migrate remaining servers 
(Place servers in the appropriate Directory tree 
containers and setup time synchronization) 





Place replicas on appropriate NetWare servers 
according to your replication strategy 





Configure time synchronization to fit your time 
synchronization strategy 





Create appropriate objects for network 
administration 





Assign container level object rights 
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Figure C-4 
Implementation Schedule Template 


Target Percent 


Task Title and Description Owner Begin Date End Date Complete 


Define user templates and create users 





Create objects for all network resources in their 
appropriate containers 





Implement file services 





Implement print services 





Create access objects and place them in their 
appropriate containers 


Create application objects and place them in their 
appropriate containers 





Create profile and user login scripts 





Assign individual NDS, Directory object properties, 
and file system rights 





Implement your data protection plan 

















Name Standards 


The following template provides an example of an Novell® Directory 
Services™ (NDS™) naming standards document. 
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Figure C-5 
Name Standards Worksheet Template 


Standard Examples Rationale 


User object common name 
(login name) 





User object last name 





User object telephone and 
fax 





User object location 





Directory tree 





Organization 





Organizational Units whose 
names are based ona 
major location 





Other OU names 





Common names of leaf 
objects other than users 





Special objects 


e Organizational Role 


e Profile 


e Directory Map 





All 
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NetWare 4 Server Worksheet 


The following template provides an example of a server worksheet 
template. 
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Server Worksheet Template 


Figure C-6 
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Directory tree information 





Server name: 











Directory context: Tree name: 





lemp. Kev 90G.9.enu.o lo Apr? 


Time Configuration 





ap_norml.enu 


Server Worksheet Template 


Figure C-7 


Time server type: Single Reference O Reference O Primary O Secondary O 


Time zone: Offset fromUTC______________ Daylight Savings: Yes O No O 





Volumes 


Volume name de lisas sae suballocation Pity migration Name space 
OFF OFF OFF 











NetWare Loadable Modules (NLM) Configuration 
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Replica Placement Worksheet 


The following template provides an example of a replica placement 


worksheet template. 


Figure C-8 
Replica Placement Template 


Servers / Site / Location 


Partitions 













































































M=master replica, R/W=read/write replica, R/O=read-only replica, SR=subordinate reference replica 
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Server Migration 


The following template provides an example of a server migration 
template. 

Figure C-9 

Server Migration Template 


Department Old ServerName Planned Name Server OS Disk Storage Comments 
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Workstation Configuration Worksheet 


The following template provides an example of a workstation 
configuration template. 
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Workstation Worksheet Template 


Figure C-10 


Workstation information 





Boot method: Hard disk O Floppy disk O Remote O Path: Disk Size: 
Memory (RAM): Base: Extended: 

















Directory tree information 





Directory context: Tree name: 











Operating System 





DOS O — Macintosh O ________ Miscrosoft O 
os20———  UNIXNFSO Windows 





Time Configuration 








Time zone: Offset fromUTC_________  Syncwith server: Yes O 


Network boards (Fill in columns that apply to each network board.) 


LAN Memory Interrupt DMA Node IPX external 
driver address (IRQ) channel address network # 





























Driver VO Memory Interrupt 
(if applicable) port address (IRQ) 





Drive Make/Model 
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appendix D 


Bibliography 


Supplemental Information 


The following publications provide supplemental information 
specifically related to NetWare® 4™ services and software. 


Following are some additional information resources on NetWare 4, 
Novell® Directory Services™ (NDS™), SMS™, and related topics. 


@ “An Introduction to Novell’s NetWare Client 32 for Windows 95,” 
Novell Application Notes, Sep 95 (Novell part no. 164-000047-009) 


@ “Applying X.500 Naming Conventions to NDS,” Novell 
Application Notes, Jan 96 (Novell part no. 164-000050-001) 


@ “Backing Up and Restoring NetWare Directory Services in 
NetWare 4,” Novell Application Notes, Aug 95 (Novell part no. 
164-000047-008) 


@ “Comparing Novell's IPX-to-IP Connectivity Solutions: IP 
Tunneling, NetWare/IP, and IP Relay,” Novell Application Notes, 
Sep 95 (Novell part no. 164-000047-009) 


@ “Configuring Asynchronous Connections with the NetWare 
MultiProtocol Router 3.0 Software,” Novell Application Notes, Jul 
95 (Novell part no. 164-000047-007) 


e “Configuring NetWare 4 for the Mobile User,” Novell Application 
Notes, Jul 94 (Novell part no. 164-000036-007) 


@ “Effectively Managing RIP and SAP Traffic with Filtering,” Novell 
Application Notes, Sep 94 (Novell part no. 164-000036-009) 


@ “Guidelines for Implementing NetWare/IP,” Novell Application 
Notes, Feb 96 (Novell part no. 164-000047-011) 
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“Implementing Naming Standards for NetWare Directory 
Services,” Novell Application Notes, Feb 94 (Novell part no. 
164-000036-002) 


“Importing User Information into NetWare Directory Services 
Using UIMPORT,” Novell Application Notes, Apr 95 (Novell part 
no. 164-000047-004) 


“Interconnecting NetWare Networks with ISDN,” Novell 
Application Notes, Sep 95 (Novell part no. 164-000050-003) 


“Novell's Corporate-Wide Upgrade to NetWare 4,” Novell 
Application Notes, Jan 94 (Novell part no. 164-000036-001) 


Novell’s CNE™ Study Guide for NetWare 4.1, David James Clarke 
IV, Novell Press, 1995 


Novell’s QuickPath to NetWare 4.1, Jeff Hughes and Blair Thomas, 
Novell Press, 1995 


Novell’s NetWare 4.1 Administrator’s Handbook, Kelley J.P. 
Lindberg, Novell Press, 1995 


“Planning an NDS Tree,” Novell Application Notes, Jan 95 (Novell 
part no. 164-000047-001) 


SMS Solutions Guide (Novell part no. 482-000209-001; call 800-346- 
6855 or 801-373-6779) 


“Time in the NetWare Environment,” Novell Application Notes, Jan 
94 (Novell part no. 164-000036-001) 


“Time Synchronization in NetWare 4.x,” Novell Application Notes, 
Nov 93 (Novell part no. 164-000032-011) 


“Troubleshooting Tips for NetWare Directory Services,” Novell 
Application Notes, Aug 95 (Novell part no. 164-000047-008) 


“Understanding and Using NDS Objects,” Novell Application 
Notes, Jan 95 (Novell part no. 164-000047-001) 


“Understanding NetWare Directory Services Rights,” Novell 
Application Notes, Apr 93 (Novell part no. 164-000032-004) 


Online Help 


“Upgrading to NetWare 4: The Chase Manhattan Bank's CC and 
FMI Groups,” Novell Application Notes, Jan 94 (Novell part no. 164- 
000036-001) 


“Upgrading to NetWare 4.1 Across a LAN/WAN Using 
RCONSOLE,” Novell Application Notes, May 95 (Novell part no. 
164-000047-005) 


“Using DS Standard to Migrate Networks to NetWare 4.1,” Novell 
Application Notes, Feb 96 (Novell part no. 164-000050-002) 


“Using NDS User Object Properties in NetWare 4.1 Login Scripts,” 
Novell Application Notes, May 95 (Novell part no. 164-000047-005) 





“Using the DOS Requester with NetWare 4.0,” Novell Application 
Notes, Apr 93 (Novell part no. 164-000032-004) 


“Using the DSMERGE Utility in NetWare 4.1,” Novell Application 
Notes, Mar 95 (Novell part no. 164-000047-003) 


“Wide Area Networking with Frame Relay and NetWare 
MultiProtocol Router,” Novell Application Notes, Feb 95 (Novell 
part no. 164-000047-002) 


The following FaxBack documents may also be helpful: 


+ 


+ 


Storage Management Systems (SMS) Model Doc. No. 1006 


Backup and Restore of NDS Doc. No. 1007 


Context-sensitive help. If you are using a NetWare menu utility 
and want more information about how to complete a task, press 
<F1>. 


If you are unsure how to use a command, type the command 
name and add the /? option for help. For example, for help with 
the RIGHTS command, type 

“RIGHTS /?”. 
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Online Windows help. The Microsoft* Windows* help viewer 
allows you to read NetWare help developed for the Windows 
environment. To access the NetWare help screens within 
Windows, press <F1> or the “Help” button. 


DynaText online documentation. The DynaText viewer allows 
you to read NetWare documentation from your DOS, Windows, 
Macintosh*, UNIX®, or OS/2* workstation. 


All NetWare 4™ documentation is available on the NetWare Online 
Documentation CD-ROM. 


Additional Help Resources 


+ 
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Customer service. You can contact your Novell Authorized 
Reseller™ representative for technical assistance. 


Most Novell Authorized Resellers have Certified NetWare 
Engineer™ representatives on their staffs ready to assist users 
with their networking problems. 


Novell Authorized Service Centers“ (NASC*™) locations. 
NASC™ facilities are local support providers authorized and 
supported by Novell. They provide both telephone and on-site 
assistance, and should be your first source for technical support. 


For the Novell Authorized Service Center nearest you, in the U.S. 
and Canada call 1-800-338-NASC. 


Hardware documentation. Many network problems occur 
because of malfunctioning hardware. 


If you can isolate a problem to a certain computer component or 
cable segment, check the manuals that came with the hardware 
involved. 


ManageWise® services. ManageWise services help you manage 
the cabling system, computers, software, and other components of 
the network. 


For more information about using NMS on your network, contact 
your Novell Authorized Reseller. 


Other Novell publications. Novell Application Notes and the 
Novell Research Reports™ publications cover technical aspects of 


NetWare-based system design, implementation, and 
management. Application Notes is a collection of technical articles 
published monthly. Research Reports is published as the research 
becomes available. 


To purchase subscriptions and back issues of these publications 
from within the United States or Canada, call the Novell 
Research Order Desk at 1-800-377-4136. From other locations, call 
303-297-2725. 


Third-party books and periodicals. Books on NetWare, including 
books published by Novell Press™ publishing, are available at 
most bookstores. 


In addition, numerous networking periodicals give advice on 
configuring, managing, and troubleshooting your network. 


NetWire® forum on the CompuServe* bulletin board. A fairly 
inexpensive way to get up-to-date advice and patches is through 
NetWire on the CompuServe bulletin board. 


To open a CompuServe account, call one of the following numbers 
and ask for Representative 200: 


+ Inthe United States or Canada: 1-800-524-3388 
+ Inthe United Kingdom: 0800-289-378 

+ In Germany: 0130-37-32 

+ In other European countries: 44-272-255-111 


+ In locations other than the United States, Canada, or Europe, 
use the appropriate country code for the U.S. and call 
614-457-0802. Ask for Representative 200. This identifies you 
as a Novell customer. 


Technical Support Database and NetWire forum on the Internet. 
The Novell internet sites support access through FIP, Gopher, and 
World Wide Web (WWW) systems. Over 9,000 documents exist on 
the WWW system for providing technical hints and information. 


To access the Novell Internet sites, log in as ANONYMOUS and 
use your e-mail address as your password. 
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Contact one of the following site addresses: 
+ Inthe United States: ftp.novell.com 
+ In Germany: ftp.novell.de 


See public areas in these sites for possible listings of other sites” 
addresses. 


To access the Novell Internet WWW sites, contact one of the 
following site addresses: 


+ In the United States: www.novell.com, www.netware.com, 
education.novell.com, corp.novell.com, wp.novell.com, 
netwire.novell.com, and iamg.novell.com. 


+ In Germany: www.novell.de 


See information areas in these sites for possible listings of other 
sites’ addresses. 


FaxBack* Service. Novell provides a FaxBack Service for 
obtaining additional product information to help with support 
needs. 


To access the Novell FaxBack Service, complete the following 
steps. 


+ Access Novell’s FaxBack Service on the Internet at: 
netwire.novell.com/home/client/misc/catalog.htm. 


+ Within the continental United States 


1. Dial 1-800-NETWARE (1-800-638-9273). 


2. Press #1 (the “Presale Product Information and Upgrade 
Information” option). 


3. Press #2 (the “Receive Product Information” option). 
4. Press #1 (the “Receive Product Information via Fax” 
option). 


+ Outside the continental United States 


Dial 1-801-861-2772. You are connected directly to the 
FaxBack Service. 


+ Follow the directions provided on the phone. You are 
prompted to enter a document number and then a fax 
number to send the document to. 


Network Support Encyclopedia Professional Volume™ (NSE 
Pro™) package. This encyclopedia gives customers access to 
regularly updated information on products and services—plus 
patches, fixes, and more—from Novell and other vendors. 


The NSE Pro package is distributed on CD-ROM on a subscription 
basis. Updates are sent out several times each year. More 
information is available on NetWire or from your Novell 
Authorized Reseller. 


Novell Consulting Services (NCS) Toolkit. This toolkit is a 
collection of documents and utilities developed and collected by 
Novell’s Consulting Services group for providing solutions to 
enterprise networks. It is packaged as a single CD-ROM. For 
information on obtaining a copy, contact Novell Consulting 
Services for details. 


Troubleshooting hardware and software. Specialized hardware 


and software packages, such as the Novell LANalyzer® software, 
are available to help you isolate network problems. 
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Vida 


Novell Trademarks 


BrainShare is a service mark of Novell, Inc. 

Client 32 is a trademark of Novell, Inc. 

Internetwork Packet Exchange and IPX are trademarks of Novell, Inc. 
LANalyzer is a registered trademark of Novell, Inc. 


ManageWise is a registered trademark of Novell, Inc. in the United 
States and other countries. 


Media Support Module and MSM are trademarks of Novell, Inc. 


NetWare is a registered trademark of Novell, Inc. in the United States 
and other countries. 


NetWare 3 is a trademark of Novell, Inc. 

NetWare 4 is a trademark of Novell, Inc. 

NetWare Application Notes is a trademark of Novell, Inc. 
NetWare Client is a trademark of Novell, Inc. 

NetWare Core Protocol and NCP are trademarks of Novell, Inc. 
NetWare DOS Requester and NDR are trademarks of Novell, Inc. 


NetWare Link Services Protocol and NLSP are trademarks of Novell, 
Inc. 


NetWare Loadable Module and NLM are trademarks of Novell, Inc. 


NetWare Message Handling Service and NetWare MHS are trademarks 
of Novell, Inc. 


NetWare Peripheral Architecture and NWPA are trademarks of Novell, 
Inc. 


NetWare Requester is a trademark of Novell, Inc. 
NetWare SQL is a trademark of Novell, Inc. 
NetWire is a service mark of Novell, Inc. 


Network Support Encyclopedia Professional Volume and NSE Pro are 
trademarks of Novell, Inc. 








Novell is a registered trademark of Novell, Inc. in the United States and 
other countries. 
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Novell Academic Education Partners and NAEP are service marks of 
Novell, Inc. 

Novell Applications Notes is a trademark of Novell, Inc. 

Novell Authorized Education Centers and NAEC are service marks of 
Novell, Inc. 

Novell Authorized Reseller is a service mark of Novell, Inc. 

Novell Directory Services and NDS are trademarks of Novell, Inc. 








Novell Labs is a trademark of Novell, Inc. 

Open Data-Link Interface and ODI are trademarks of Novell, Inc. 
Packet Burst is a trademark of Novell, Inc. 

Personal NetWare is a trademark of Novell, Inc. 

SFT (System Fault Tolerance) and SFT III are trademarks of Novell, Inc. 
The Novell Network Symbol is a trademark of Novell, Inc. 
Transaction Tracking System and TTS are trademarks of Novell, Inc. 
Virtual Loadable Module and VLM are trademarks of Novell, Inc. 
Yes, It Runs with NetWare (Logo) is a trademark of Novell, Inc. 

Yes, NetWare Tested and Approved (Logo) is a trademark of Novell, 
Inc. 


Third-Party Trademarks 


Apple and AppleTalk are registered trademarks of Apple Computer, 
Inc. 

CompuServe is a registered trademark of CompuServe Incorporated. 

IBM is a registered trademark of International Business Machines 
Corporation. 

Local Area Network Server (LAN Server) is a trademark of 
International Business Machines Corporation. 


LAN Manager is a trademark of Microsoft Corporation. 

Macintosh is a registered trademark of Apple Computer, Inc. 

Microsoft is a registered trademark of Microsoft Corporation. 

Network Archivist is a trademark of Palindrome Corporation. 

NFS is a registered trademark of Sun Microsystems, Inc. 

OS/2 is a registered trademark of International Business Machines 
Corporation. 

Unicode is a registered trademark of Transoft Ltd. 

UNIX is a registered trademark of X/Open Company, Ltd. 

Windows is a registered trademark of Microsoft Corporation. 

Windows 95 is a trademark of Microsoft Corporation. 
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WordPerfect is a registered trademark of Corel Corporation Limited. 
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Access performance, providing 
with replicas 94 
Across-the-wire upgrade, using DS Migrate 
(See also DS Migrate) 204 
Add or Delete Self property right, explained 
149. See also Rights 
ADMIN User object 
default location in Directory tree 82 
default rights, listed 82 
AFP Server object, explained 70, 273 
Alias object 
explained 70, 270 
Application compatibility, explained 181 
Application directories, creating 182 
Application management 
guidelines 190 
identifying efficient tools 185 
using NetWare Application Manager 
benefits 187 
Application object, explained 71, 266 
Attributes. See Object properties 
Auditing File object, explained 71, 266 
Auditing leaf objects, listed and explained 
266 
Authentication, explained 142. See also 
Security 


Automatic Client Upgrade (ACU), described 
203 


B 


Bindery context, setting 
multiple, overview 137 
necessary for Novell Directory Services 
138 
to replica 140 
Bindery Object object, explained 270. See also 
Objects 
Bindery objects. See also Objects 
created /upgraded under Novell Directory 
Services 139 
Bindery Queue object, explained 270. See also 
Objects 
Bindery services 
disabling, explained 138 
illustrated 137 
when Novell Directory Services can't 
support 138 
Bindery services, using with Novell Directory 
Services 
bindery context not set, caution 138 
limited partitioning 140 
objects created /upgraded 139 
overview 137 
Browse object right, explained 148. See also 
Rights 
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Changing. 
context, explained 130 
Changing. See also Modifying 
names after implementing Novell 
Directory Services 48 
Characters, using in names 
Unicode 49 
Child partition, defined 88. See also Partitions 
Classes, object. See Object classes 
Client migration 
critical factors, identifying 196 
installing 196 
method, determining 195 
process, automating 202 
Common name, defined 127 
Compare property right, explained 149. See 
also Rights 
Complete name. See Distinguished Name 
Computer object, explained 71, 267 
Configuration, using custom (to set time 
synchronization) 120. See also Time 
synchronization 
Consultative Committee for Telegraphy and 
Telephony (CCITT), X.500 standard 
explained 40 
Container login script, explained 155 
Container objects. See also Objects; specific 
container object name or type 
Country (C) 54 
Locality (L) 55 
Organization (O) 56 
Organizational Unit (OU) 56 
Container objects. See also Objects; specific 
container object name or type 
Licensing Product (LP) 55 
Context 
changing name, explained 130 
defined 127 
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Country (C) container object. See also 
Container objects 
explained 54 
Create object right, explained 148. See also 
Rights 
Creating, for Directory tree 
structure (see Directory tree structure) 
Custom configuration, using to set time 
synchronization 120. See also Time 
synchronization 


D 


Default login script. See also Login scripts 
explained 156 
Delete object right, explained 148. See also 
Rights 
Delete Self property. See Add or Delete Self 
property 
Design phase schedule, creating 36 
Directory 
schema, explained. See also Directory tree) 
41 
subtree, defined 88 
synchronization, explained 95 
Directory fault tolerance, providing 
with replicas 93 
Directory Map object 
explained 72, 273 
Directory objects. See also Objects 
naming standards (see Naming standards) 
property information standards 45 
Directory objects. See also Objects 
classes, explained 40 
defined 40 
explained 40 
Directory partition replicas. See Replicas 
Directory tree 
boundaries, establishing 56 
foundation design, determining 54 


naming 53 
schema, explained 41 
structure design, reviewing 68 
structure, planning 52 
subtree, defined 88 
upper layers, designing 53 
Directory tree structure, creating (guidelines). 
See also Directory tree, planning 
for large network 242 
for medium network 238 
for small network 235 
Directory tree, planning. See also Directory 
tree structure 
and Novell Directory Services 
implementation. See Novell Directory 
Services technology, implementing 
42 
Disabling bindery services, explained 138. See 
also Bindery services 
Distinguished Name 
defined 127 
Distribution List object 
explained 72, 268 
DOS Requester. See NetWare DOS Requester 
Drive mapping 
Directory Map object, explained 72, 273 
DS Migrate 
operation of, illustrated 204 


E 


External Entity object 
explained 72, 268 


F 


Fault tolerance. See Directory fault tolerance 
File and directory rights. See Attributes, 
directory 


File attributes. See Attributes, file 


G 


Group object 
explained 73,275 
Guidelines 
for copying replicas (see Replicas, copying) 
for creating partitions (see Partitions, 
creating) 
for setting up time services (see Time 
services, setting up) 


Identifier variables 
conventions in login scripts 158 
Information, inaccessible (when using 
bindery services with Novell Directory 
Services) 140 
Informational leaf objects, listed and 
explained 267. See also Objects 
Inherited Rights Filter (IRF). See also Security 
explained 144 
planning 160 
INSTALL.NLM 
operation of, illustrated 204 
requirements for using 204 


L 


Large network, implementing Novell 
Directory Services on 
general guidelines 230 
specific guidelines 240 
Leaf objects, listed and explained. See also 
Objects; specific leaf object name or type 
auditing 266 
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general 69 
informational 267 
messaging-related 268 
miscellaneous 270 
NetWare Licensing Services 271 
placement, determining 77 
printer-related 272 
server-related 273 
user-related 275 
Licensing Product (LP) container objects, 
explained 55 
Locality (L) container objects, explained 55. 
See also Container objects 
Login scripts 
default, explained 156 
identifier variables, conventions 158 
profile, explained 155 
types, explained 155 
user, explained 155 
Login scripts, creating 
planning 156 
rules 157 
Lower tree layer 
designing 62 
framework, determining 63 
Lower tree layer framework 
common access containers, forming 64 
management structure containers, forming 
65 
services containers, forming 67 
specific design elements, incorporating 67 
workflow containers, forming 65 
Lower tree layer framework design elements 
network infrastructure 67 
number of objects 67 
scalability and distribution 67 
tree depth and name length 68 
LSP Server object 
explained 73,271 
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Macintosh client, new features, described 201 
Master replica, explained 94. See also Replicas 
Medium network, implementing Novell 
Directory Services on 
general guidelines 230 
Message Routing Group object 
explained 73, 269 
Messaging Server object 
explained 73, 269 
Messaging-related leaf objects, listed and 
explained 268. See also Objects 
Metering 
explained 188 
using NetWare Licensing Services (NLS) 
188 
Methods of upgrading 
defined 204 
MIGRATE.EXE 
operation of, illustrated 204 
Miscellaneous leaf objects, listed and 
explained 270. See also Objects 


N 


Name 
context, changing (see also Context) 48, 130 
Naming standards 
backwards compatability, identifying 
considerations 48 
considerations, identifying 47 
consistency, identifying considerations 48 
conventions, identifying considerations 51 
modifying 48 
name length, identifying considerations 48 
template, using 45 
NetWare Application Launcher (NAL), 
described 186 





NetWare Application Manager (NAM), 
described 185 
NetWare Client 32, described 198 
NetWare Client for Mac OS. See Macintosh 
client 201 
NetWare Client for OS/2. See OS/2 client 
software 
NetWare DOS Requester, new features 
described 199 
NetWare File Migration utility 
operation of, illustrated 204 
NetWare Licensing Services (NLS), described 
188 
NetWare Licensing Services leaf objects, listed 
and explained 271 
NetWare Server object 
explained 74, 274 
NetWare Server object naming rules, 
explained 51 
Network application 
compatibility with NetWare 181 
explained 179 
installation and upgrade 187 
licensing 188 
load balancing explained 183 
managing 185 
metering 188 
protecting 184 
Network resources 
object placement, planning 69 
object representation, explained 69 
Network types, explained 43 
NO_DEFAULT login script command, using 
156 
Novell Directory Services technology, 
implementing (guidelines) 
on any network 230 
on large network 240 
on medium network 236 
on small network 234 








O 


Object classes 
listed and explained 247 
properties, listed (see also Object Properties) 
250 
Object placement 
global resources, determining 80 
Server object, determining 79 
used by mobile users, determining 79 
Object properties. See also specific object 
property name or type 
classes, listed 250 
defined 40 
explained 40 
Object rights, listed and explained 147. See also 
Rights 
Objects. See also specific objects 
with login scripts 157 
Organization (O) container object. See also 
Container objects 
explained 56 
Organization object 
login script (see Login scripts) 
Organizational Role object 
explained 74, 275 
Organizational Unit (OU) container object. See 
also Container objects 
explained 56 
Organizational Unit object 
login script (see Login scripts) 
OS 7/2 client software 
new features, described 200 
Other upgrade methods. See Upgrade 
methods, alternatives to this manual 


P 


Parent 
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partition, defined 88 (see also Partitions) 


Partial name. See Relative Distinguished 
Name 
Partition boundaries 
characteristics, considering 88 
forming 88 
layout, planning 90 
Partition placement 
strategy, determining 93 
Partition planning 
boundaries, determining 90 
creation requirements, determining 87 
for lower layers, designing 92 
for upper layers, designing 91 
size and number, determining 92 
Partition replicas. See Replicas 
Partition Root Entry, defined 88. See also 
Partitions 
Partition root object 
defined 88 
Partitioning 
defined 85 
explained 86 
limited 140 
Partitions, creating (guidelines) 
in large network 244 
in medium network 239 
in small network 236 
Partitions. See also specific partition type 
parent and child, illustrated 88 
Planning 
login scripts 156 
Print Queue object, explained 74, 272 
Print Server object, explained 74, 272 
Printer object, explained 75, 272 
Printer-related leaf objects, listed and 
explained 272. See also Objects 
Profile login script. See also Login scripts 
explained 155 
Profile object 
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explained 75, 275 


Project 


critical design factors, indentifying 35 
design complexity, determining 35 
design phase schedule, creating 37 
design scope, defining 34 
expectations, identifying 36 
information types, determining 29 


Project team 


Application specialist responsibilities, 
explained 21 

Education and training coordinator 
responsibilities, explained 23 

function, explained 15 

MIS manager responsibilities, explained 
17 

NDS expert responsibilities, explained 18 

organization, described 15 

Printing specialist responsibilities, 
explained 21 

responsibilities, identifying 17 

roles, identifying 16 

Routing specialist responsibilities, 
explained 22 

Server specialist responsibilities, explained 
19 

skills, assessing 16 

Training lab coordinator responsibilities, 
explained 23 

training needs, determining 24 

Workstation specialist responsibilities, 
explained 20 


Properties. See Object properties 
Property rights. See also Rights; specific 


property right name 
explained 148, 149 
listed 149 


Property value, defined and explained 40 


Q 


Queue object. See Print Queue object 


R 


RDN. See Relative Distinguished Name 
Read property right, explained 149. See also 
Rights 
Read/write replica, explained 94. See also 
Replicas 
Read-only replica, explained 95. See also 
Replicas 
Relative Distinguished Name (RDN), defined 
128 
Rename object right, explained 148. See also 
Rights 
Replica placement 
designing 100 
for accessibility 100 
for fault tolerance 100 
navigation 101 
Replicas 
basic functions, identifying 93 
characteristics, considering 93 
list, defined 96 
ring, defined 96 
types, listed and explained 94 
Replicas, copying (guidelines) 
on large network 244 
on medium network 239 
on small network 236 
Replication 
defined 85 
explained 86 
Rights, file system 
assigning to trustee 143 
default 82 
Rights, object 


default for User ADMIN 82 
Rights. See also Security; specific right type 

granted at installation, to ADMIN 159 
Root partition, defined 88. See also Partitions 
[Root] partition 

creating 90 

explained 90 


S 


Same-server upgrade, explained 205 
SAP. See Service Advertising Protocol 
Schema, Directory See also Directory tree 41 
Security. See also Directory fault tolerance; 
Properties; Rights; Time 
synchronization 
authentication, explained 142 
Inherited Rights Filter, explained 144 (see 
also Inherited Rights Filter) 
Server migration 
method, determining 204 
Server object 
explained 82 
Server utilities 
listed and described 217 
Server-related leaf objects, listed and 
explained 273. See also Objects 
Service Advertising Protocol (SAP), setting 
time synchronization with 119. See also 
Time synchronization 
Setting up 
time services (see Time services) 
Shared resources, determining object 
placement 79 
Small network, implementing Novell 
Directory Services on 
general guidelines 230 
specific guidelines 234 
Structure, Directory tree. See Directory tree 
structure 
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Subordinate reference replica, explained 95. 
See also Replicas 

Subtree, Directory (defined) 88 

Supervisor right, explained. See also Rights 
object 148 
property 149 

Synchronization 
Directory, explained 95 


T 


Tape backup device, upgrading using, 
illustrated 205 
Template examples 
application compatibility 277 
implementation schedule 279, 286 
listed 277 
name standards 45, 281 
NetWare 4.11 server worksheet 283 
server migration 287 
workstation configuration worksheet 289 
Time servers. See also specific time server type 
using custom configuration for 120 
Time services, setting up (guidelines) 
for large network 243 
for medium network 238 
for small network 236 
Time source 
efficient configuration, determining 114 
for external time synchronization 114 
for internal time synchronization 113 
Time source configuration 
single reference time server, using 115 
time provider group, using 116 
Time synchronization 
communication format, identifying 119 
communication format, using a 
combination 121 
communication format, using custom 
configuration list 120 
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communication format, using Service 
Advertising Protocol (SAP) 119 
strategy, determining 109 
strategy, using external time source 112 
strategy, using internal and external time 
sources 112 
strategy, using internal time source 108 
Training 
opportunities, identifying 26 
topics, identified 24 
Tree walking, providing 
with replicas 94 
Tree. See Directory tree 


U 


Unicode characters, using in names 49 
Unknown object, explained 270. See also 
Objects 
Upgrade methods 
alternatives to this manual 205 
defined 204 
Upper tree layer boundaries 
Organization layer, forming 57 
Regional and location layer, forming 58 
User login script. See also Login scripts 
explained 155 
NO_DEFAULT command, using 156 
User object 
explained 75, 276 
User object ADMIN. See ADMIN User object 
User-related leaf objects, listed and explained 
275. See also Objects 
Utilities 
server, new features described 217 
Utilities. See also Server utilities; Workstation 
utilities 
workstation, new features described 217 


V 


Volume object 
explained 76, 274 


W 


WAN link 
using partitions for faster access across 94 
Write property right, explained 149. See also 
Rights 


X 


X.500, defined 40 


Y 


Yes program, certification criteria 181 
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User Comments 


We want to hear your comments and suggestions about this manual. Please send them to the following 
address: 


Novell, Inc. Place Product Name and 
Documentation Development Version Here 

MS C-23-1 Place Book Title Here 

122 East 1700 South Part #Place Part Number Here 
Provo, UT 84606 Place Release Date Here 
U.S.A 


Fax: (801) 861-3002 


For technical support issues, contact your local dealer. 


Your name and title: 





Company: 





Address: 











Phone number: Fax: 





l use this manual as QO an overview UO atutorial QO areference Q aguide O 


Excellent Good Fair Poor 
Completeness Q a a a 
Readability (style) a a a Q 
Organization/Format Q Q Q Q 
Accuracy a a Q Q 
Examples a a a a 
Illustrations a a a O 
Usefulness a a a a 














Please explain any of your ratings: 

















In what ways can this manual be improved? 

















You may photocopy this comment page as needed so that others can also send in comments. 


